June 2019 - Ffmpeg-devel-irc - lists.ffmpeg.org

ffmpeg-devel.log.20190621
by burek 22 Jun '19

22 Jun '19

[00:15:15 CEST] <llogan> twitter user wants to know -q:a range for aac. anyone know? i'm unable to look at code ATM. https://twitter.com/Bardnet/status/1141798687200485376 [08:33:29 CEST] <cone-496> ffmpeg 03greg Luce 07master:18dab6175bad: doc/filters: drawtext additions and corrections [10:13:23 CEST] <durandal_1707> JEEB: thanks for spreading misinformation to my student, you are lost [11:15:23 CEST] <durandal_1707> vel0city: you could look how libavcodec/tdsc.c handle it [11:43:05 CEST] <JEEB> durandal_1707: hah, I didn't know we were OK with having it like that :P [11:43:54 CEST] <JEEB> because that seems like a clear break in container vs codec [11:45:06 CEST] <JEEB> durandal_1707: and the only reason something like that was done is because of image2 [11:46:13 CEST] <JEEB> for me it is clear that if something is like TIFF (which is a container for images), then the container side of things belongs to lavf, and then you give out either raw images or JPEG or whatever else :P [11:47:39 CEST] <JEEB> I think TSDC is kind of special since it's a codec that can do either X or Y [11:47:52 CEST] <pross> i am going to push that ifv cctv demuxer [11:50:00 CEST] <JEEB> or any other actual codec codec that is already in a container, compared to TIFF which is a container in itself [11:50:22 CEST] <JEEB> or at least my *understanding* is that TIFF is a container [11:50:55 CEST] <JEEB> I can be incorrect of that, and if so please feel free to correct me :P [11:51:19 CEST] <pross> student waiting month for feedback on small demuxer task is not good imho. [11:51:41 CEST] <JEEB> and the fact that we currently have that container implementation in lavc is just an original design decision [11:51:54 CEST] <JEEB> pross: I agree, who was handling that one? :/ [11:52:05 CEST] <JEEB> or was that just a student not yet in anything [11:53:04 CEST] <pross> i am first to admit i have not paid attention to this at all. google website says carl [11:59:39 CEST] <JEEB> durandal_1707: also it seemed like the images within the TIFF would be alternative images (JPEG version and raw version, for example). not sure you want to just abstract that within a single AVStream :P [12:00:08 CEST] <JEEB> also I was not being an asshole because I clearly saw that the code currently resided in lavc [12:01:58 CEST] <JEEB> lavf's tiff side could be minimal for now, depending on what the actual case is (raw vs jpeg f.ex.) [12:02:09 CEST] <JEEB> but hey, I could be completely incorrect and TIFF is not a container [12:02:18 CEST] <JEEB> in which case yes, I've been spouting bullshit [12:44:38 CEST] <durandal_1707> JEEB: TIFF is not container, there are many tiles, each encoded as jpeg image in TIFF, all tiles make one big image [12:48:14 CEST] <JEEB> ok. if that is true then the best thing would be if those tiles could be exported as a single JPEG in the end, but if not - then that's similar to HEIF and it sucks and sub-AVCodecContext might be acceptable :P [12:48:34 CEST] <JEEB> thank you for correcting [12:48:55 CEST] <JEEB> (I'm pretty sure you could have alternative images in TIFF, but that is anyways a separate thing) [12:49:24 CEST] <durandal_1707> there are, no reason to use AVStreams [12:49:38 CEST] <JEEB> ok, how would you export those? attachments? [12:49:55 CEST] <durandal_1707> AVOptions [12:50:36 CEST] <JEEB> is that just so you don't have to deal with lavf vs lavc? or do you seriously believe that you shouldn't export them by default in some way? [12:50:56 CEST] <JEEB> also this explanation does seem like TIFF is a container, but the specific thing we're handling right now is not relevant to that [12:50:57 CEST] <durandal_1707> you can have list of TIFFs [12:51:22 CEST] <durandal_1707> so you need AVStreams within AVStreams [12:53:10 CEST] <JEEB> well yes, image2 currently lets you have multiple image files as a single AVStream sequence. which I understand is a problem if you start moving things to lavf. but at that point it seems like it's a problem in the fact that we do not have a generic playlist/sequence thing :P [12:53:30 CEST] <JEEB> (I think we have the concat thing by now but no idea how well it works) [12:55:42 CEST] <JEEB> and nothing is perfect and we won't get things to be perfect with a single sweep. but we should look into the limitations of our systems right now, and how we might want that in the future [14:03:12 CEST] <cone-731> ffmpeg 03Swaraj Hota 07master:d70fece5609f: avformat/ifv: added support for ifv cctv files [16:35:07 CEST] <kepstin> llogan: i took a look and it seems like the aac qscale range is 0 < qscale <= 10 (if you set it to 0 or lower it's treated as ~1, if you set it to >10 i think it does an out of bounds array index on psy_vbr_map in aacpsy.c) [16:37:53 CEST] <kepstin> oh, hmm, 0 is treated as approximately 1, negative values probably do bad things. [16:51:04 CEST] <kepstin> huh, unless I'm misreading something, several codecs document qscale values < 0, but ffmpeg_opt.c ignores the option unless you pass a value >= 0 [17:42:08 CEST] <cone-731> ffmpeg 03Derek Buitenhuis 07master:d5a6b390ced6: ffprobe: Fix memory leak [18:29:47 CEST] <cone-731> ffmpeg 03Michael Niedermayer 07master:dd8720045cdc: avcodec/wcmv: check remaining space vs. blocks [18:29:48 CEST] <cone-731> ffmpeg 03Michael Niedermayer 07master:561cc161ca61: avcodec/fmvc: Check if header fields are available before allocating the image [18:29:49 CEST] <cone-731> ffmpeg 03Michael Niedermayer 07master:902b06f2d4a7: avformat/tiertexseq: Move seq_read_close() up so it can be used for cleanup [18:29:50 CEST] <cone-731> ffmpeg 03Michael Niedermayer 07master:8e3e63e9ac18: avformat/tiertexseq: Cleanup on error [18:29:51 CEST] <cone-731> ffmpeg 03Michael Niedermayer 07master:112eb17a2bbf: avformat/wsddec: Fix undefined shift [18:29:52 CEST] <cone-731> ffmpeg 03Michael Niedermayer 07master:54918b511616: avformat/icodec: Free ico->images on error paths [18:29:54 CEST] <cone-731> ffmpeg 03Michael Niedermayer 07master:06a90cc78385: avformat/jacosubdec: Fix timeres to 1/100 units convertion overflow [18:29:54 CEST] <cone-731> ffmpeg 03Michael Niedermayer 07master:8c6c2747bc85: avformat/vividas: Fix invalid shift in decode_key() [18:29:55 CEST] <cone-731> ffmpeg 03Michael Niedermayer 07master:01d8c72b95b9: avformat/vividas: reduce keybits to require half the space [00:00:00 CEST] --- Sat Jun 22 2019

1 0

ffmpeg.log.20190621
by burek 22 Jun '19

22 Jun '19

[00:00:00 CEST] --- Fri Jun 21 2019 [03:17:18 CEST] <^Neo> If I want to stream some MPEG-TS stream within a single host machine, is the preferred method using RTP? [03:27:48 CEST] <kevinnn> hi all, I am having some trouble with artifacting right now in my stream [03:27:54 CEST] <kevinnn> increasing i_slice_max_size to 10000 [03:28:00 CEST] <kevinnn> resolves like 99% of the artifacting [03:28:06 CEST] <kevinnn> but increases the bandwidth to a number that is not acceptible [03:28:13 CEST] <kevinnn> are there any other solutions? [03:28:20 CEST] <kevinnn> I don't mind giving up some CPU power or stream quality [03:28:27 CEST] <kevinnn> just no artifacting [03:28:33 CEST] <kevinnn> also I can't give up on latency either [03:28:36 CEST] <kevinnn> thanks! [03:34:20 CEST] <DHE> kevinnn: you're gonna need to specify a lot more detail. plus I can't even find that option in ffmpeg -h full on my system [03:36:39 CEST] <kevinnn> DHE: I am using x264.h directly via c++ [03:37:04 CEST] <DHE> oh... well this is ffmpeg [03:37:22 CEST] <kevinnn> here is my full x264 config [03:37:23 CEST] <kevinnn> https://pastebin.com/W99KbK1v [14:54:57 CEST] <grosso> is av_packet.side_data automatically deallocated at av_packet_unref? [14:56:09 CEST] <DHE> yes [14:56:13 CEST] <JEEB> > av_packet_free_side_data(pkt); [14:56:17 CEST] <JEEB> in av_packet_unref [14:56:18 CEST] <JEEB> so yes [14:59:11 CEST] <grosso> thanks [15:00:13 CEST] <DHE> tfw you run ffmpeg under valgrind to try and find a memory leak [15:00:15 CEST] <DHE> :/ [15:00:19 CEST] <DHE> (yes I've done that) [15:00:23 CEST] <JEEB> yes [15:00:35 CEST] <JEEB> same here, and generally I've tested my patches so that there's no memleaks [15:01:12 CEST] <DHE> #5799 found one in the release version of ffmpeg [17:58:30 CEST] <sklv> hi i have this script to convert wmvs to mp4 and i'm trying to make it decode the progress informatino so i can calculate an eta http://ix.io/1MpA [17:59:20 CEST] <sklv> the issue is it captures all the lines *except* the ones with the progress information - any idea why? #python says it could be because ffmpeg detects if its running in a pty [18:06:03 CEST] <DHE> sklv: that's possible. you should be able to force it with -stats 1 though [18:10:14 CEST] <sklv> that gives an error but just -stats on its own runs but doesn't make a difference [18:10:30 CEST] <sklv> I think i will pipe to a log file and tail the log file [00:00:00 CEST] --- Sat Jun 22 2019

1 0

ffmpeg-devel.log.20190620
by burek 21 Jun '19

21 Jun '19

[00:22:58 CEST] <iive> jya, why not use vdpau in firefox? [00:23:41 CEST] <jya> iive: one thing at a time, and there's far more people with an intel GPU on linux than nvidia [00:23:59 CEST] <jya> and vdpau is now deprecated [00:24:37 CEST] <iive> mesa3d supports vdpau for all radeons too. nvidia depricated it, but it is still supported. i think they opensourced it too. [00:25:34 CEST] <jya> AFAIK, it's always been open sourced [00:26:34 CEST] <iive> not always, but it was open sourced long ago. [00:27:01 CEST] <iive> what i mean, it is higher level and should be easier to support. [00:27:39 CEST] <jya> ease of implementation isn't really a concern here. [00:28:11 CEST] <jya> i see no point in adding support for an already deprecated API. [00:37:19 CEST] <iive> jya, i can't find official deprecation notice with google. could you provide me with a link? [02:33:52 CEST] <vel0city> how do I use a decoder from another one? [02:34:11 CEST] <vel0city> like, in my case I want to use ff_mjpeg_decode_frame from tiff.c's decode_frame [02:34:58 CEST] <jlut> iive: vdpau is not officially deprecated afaik, just that nvidia released nvdec (for newer chipsets and with vp9) and amd has amx now. things dont look good for vdpau [02:35:13 CEST] <jlut> amf* [02:37:08 CEST] <iive> jlut, what is the point of video acceleration api, if each manufacturer is going to make its own incompatible api... [02:37:34 CEST] <jlut> ik its quite sad :( [02:39:07 CEST] <iive> vdpau is mostly good API. [02:43:11 CEST] <jlut> yeah, but hopefully in the future we can have nvdec/amx backends for vaapi. everyone will support vaapi, life will be good. oh well. [02:47:41 CEST] <iive> is there somebody who likes vaapi? [02:50:02 CEST] <jlut> idk it is the most supported one, given how chrome/firefox also plan to implement it. its the only open API standard left, if we assume vdpau will die. [03:07:32 CEST] <iive> it is kind of circular logic [03:07:57 CEST] <iive> whatever is supported would become the supported standard. [03:13:46 CEST] <iive> n8 ppl [03:16:51 CEST] <jlut> yeah tru. n8 [03:36:05 CEST] <kierank> jamrial: I think the UB stuff isn't too bad, but the timeout stuff is silly [05:09:31 CEST] <cone-064> ffmpeg 03Bodecs Bela 07master:86f04b918c0d: avformat/hlsenc: enhanced %v handling with variant names [10:43:40 CEST] <grosso> hi [10:43:51 CEST] <grosso> Do you offer courses on ffmpeg developing? [10:44:32 CEST] <JEEB> not yet at least [10:44:53 CEST] <JEEB> although every now and then someone has some time to go through a bit of hand-holding on the user channel for API usage [10:47:42 CEST] <grosso> I have a problem very difficult to solve. I've been looking into the code to figure out how things work, but it is die-hard. I need some developer into the flv format and h264 and aac codecs to help me.. I can pay for it [11:13:55 CEST] <willson> test [14:34:21 CEST] <cone-047> ffmpeg 03Gyan Doshi 07master:91f5950f833f: avformat/segment: fix muxing tmcd tracks in MOV [19:05:50 CEST] <vel0city> how do I use a decoder from another one? [19:05:59 CEST] <vel0city> like, in my case I want to use ff_mjpeg_decode_frame from tiff.c's decode_frame [19:06:46 CEST] <vel0city> but the former of course accepts an MJpegDecodeContext [19:07:08 CEST] <vel0city> so how to bridge the gap? [19:10:44 CEST] <JEEB> ok, so in a perfect world due to TIFF being essentially an image container you'd have it be an avformat thing, and then it would set the correct AV_CODEC_ID (which would be JPEG or raw or whatever) [19:11:14 CEST] <JEEB> but atm it seems like tiff is a decoder in libavcodec only [19:11:32 CEST] <JEEB> which is then utillized through the meta demuxer/muxer for images :P [19:11:44 CEST] <JEEB> ("raw" images specifically) [19:12:03 CEST] <JEEB> vel0city: I'm not sure how hard it would be to move tiff to be like that [19:13:31 CEST] <JEEB> alternatively, you could initialize a sub-AVCodecContext for JPEG, and then call into that. but that is just :< since it breaks the abstraction of format vs actual image data [19:14:21 CEST] <vel0city> hm [19:15:31 CEST] <vel0city> idk, I'm definitely not familiar enough with the codebase that I'd feel comfortable converting tiff to libavformat [19:16:06 CEST] <JEEB> basically the part which decides if it's raw or JPEG or whatever would have to be re-created on lavf side [19:16:22 CEST] <JEEB> and then the decoder itself can be kept on the other side for as long as required [19:17:09 CEST] <vel0city> oh I see [19:18:08 CEST] <vel0city> so lavf side can only basically pick an enum? [19:18:21 CEST] <vel0city> because it's not like we I can direct it straight to mjpegdec [19:18:32 CEST] <JEEB> no, it provides the data packets as well [19:18:39 CEST] <JEEB> it's the part that parses the container [19:18:40 CEST] <vel0city> it needs processing because TIFFs contain tils of separate jpegs [19:18:48 CEST] <vel0city> DNGs* [19:18:50 CEST] <JEEB> and provides AVPackets that can be fed into a decoder [19:19:05 CEST] <vel0city> so it can call into the decoder multiple times? [19:19:15 CEST] <vel0city> for a single frame [19:19:21 CEST] <JEEB> no, it just provides the interfaces to read the AVStreams' contents from a container [19:19:24 CEST] <JEEB> for example if you know mp4 [19:19:34 CEST] <JEEB> a demuxer reads its index, generates all relevant AVStreams [19:19:47 CEST] <JEEB> and then the user can read packets from the container and apply them to matching decoders [19:19:58 CEST] <JEEB> demuxers read containers and provide their data [19:20:05 CEST] <JEEB> decoders decode provided data [19:20:27 CEST] <JEEB> so TIFF is a container that can have either raw or JPEG or whatever [19:20:45 CEST] <JEEB> and then the actual image data within would be AVPackets [19:21:31 CEST] <JEEB> and if there's multiple images in the container you can either provide them as separate AVStreams, or as separate AVPackets within a single AVStream [19:21:45 CEST] <JEEB> of course, they should all be the same codec in the AVStream :P [19:22:12 CEST] <JEEB> a decoder should not be concerned about container level things, which is what the tiff decoder currently is doing [19:22:24 CEST] <JEEB> it's doing that just because it was originally implemented so that the lavf part is 100% pass-through [19:22:27 CEST] <JEEB> :P [19:22:46 CEST] <JEEB> but as soon as you get to something like this you actually can't do that any more [19:23:00 CEST] <JEEB> which was a problem coming to roost because TIFF is a container, and not only for raw images [19:23:11 CEST] <JEEB> for just raw images you can set the pixel format to whatever matches and provide those :P [19:24:32 CEST] <JEEB> so currently what happens is libavformat/img2dec.c has an entry registered for tiff [19:24:37 CEST] <JEEB> > IMAGEAUTO_DEMUXER(tiff, AV_CODEC_ID_TIFF) [19:24:57 CEST] <JEEB> which then calls tiff_probe [19:25:27 CEST] <JEEB> and if that probe matches, it literally just provides the data as-is to the tiff "decoder" [19:27:06 CEST] <JEEB> while the correct way would be that lavf would have the thing that handles the TIFF container side and would either provide the raw images as the raw video avcodec id, or the compressed JPEG frames with the JPEG avcodec id [19:27:57 CEST] <JEEB> vel0city: I hope this is all clear and unfortunately compressed stuff within TIFF was never a theme when the TIFF support was originally made. I'm sorry. [19:29:51 CEST] <vel0city> @JEEB: it's clear, thanks for explaining [19:31:28 CEST] <vel0city> I suppose I'll look into lavf then, I've never done anything with it [19:31:49 CEST] <vel0city> so the solution would involve removing tiff stuff from img2dec right? [19:32:37 CEST] <JEEB> yes [19:32:54 CEST] <JEEB> you would build a libavformat/tiffdec.c [19:33:30 CEST] <vel0city> "dec"? I thought it was supposd to demux not decode [19:33:31 CEST] <JEEB> which would parse the TIFF structure, decide streams and their types etc, and be the thing that provides the compressed or uncompressed frames to decoders [19:33:38 CEST] <JEEB> vel0city: it's a wording in the code base :) [19:33:48 CEST] <JEEB> dec/enc is used both in lavc and lavf [19:34:08 CEST] <vel0city> right [19:35:30 CEST] <vel0city> so, would it be feasible - as a first goal - to make this lavf file directly use tiff.c as it is now? [19:37:49 CEST] <JEEB> I'd guess yes, as a kludge [19:38:07 CEST] <JEEB> you set AV_CODEC_ID to TIFF and when packet is requested you give the whole thing or whatever [19:38:15 CEST] <JEEB> (not sure how img2 exactly works) [19:39:21 CEST] <JEEB> while for the JPEG part you would have to parse the actual JPEG image [19:39:27 CEST] <JEEB> and pass that on [19:39:47 CEST] <vel0city> ah and it would create the correct AVCodecContext/TiffContext'es by itself? [19:40:27 CEST] <JEEB> the format specific stuff (jpeg, "tiff", etc) is internal, but the API user would effectively then create an AVCodecContext of the right type [19:40:38 CEST] <JEEB> since you export the AVStream with the correct one [19:41:24 CEST] <JEEB> anyways, will try to do some jogging so be back in a while [19:41:37 CEST] <vel0city> cool [19:59:27 CEST] <cone-883> ffmpeg 03Andreas Rheinhardt 07master:a1a8815220fc: libavcodec: Reduce the size of some arrays [22:15:10 CEST] <JEEB> https://developer.apple.com/av-foundation/HEVC-Video-with-Alpha-Interoperab… [22:15:13 CEST] <JEEB> what a lovely spec [22:15:28 CEST] <JEEB> also TIL there's an alpha layer SEI [22:47:30 CEST] <TD-Linux> can't decide if that is better or worse than webm alpha [23:32:35 CEST] <jamrial> JEEB: well, the sample in the ticket above already isn't following that spec. it has one sps and one pps, when it's supposed to be two [23:33:35 CEST] <JEEB> lol [00:00:00 CEST] --- Fri Jun 21 2019

1 0

ffmpeg.log.20190620
by burek 21 Jun '19

21 Jun '19

[05:57:36 CEST] <nine_milli> blb i see ya [07:07:24 CEST] <pk08> hi [07:07:46 CEST] <pk08> is it possible to have 2 inputs in ffplay's filter [07:08:23 CEST] <pk08> i need 2 input stream in ffplays filter: one audio stream and one video stream for showvolume filter [07:09:30 CEST] <pk08> in ffplay's manual, i see only one input and one output is possible in -vf and -af [07:09:55 CEST] <pk08> and i want combination of both filters... [07:10:20 CEST] <pk08> so anyone have any any idea how can i do that? [07:10:44 CEST] <pk08> or is there any alternative for this [07:25:09 CEST] <Atlenohen> Hello [07:26:44 CEST] <Atlenohen> does ffmpeg support m3u8 manifest assisted chunk concat? So that it accounts for timecodes properly?

1 0

ffmpeg-devel.log.20190619
by burek 20 Jun '19

20 Jun '19

[09:43:41 CEST] <durandal_1707> michaelni: thank you very much, you made yet another developer to leave due to your f* bad patches, for how long? [11:46:56 CEST] <michaelni> durandal_1707, i do not know what you talk about. What patch? who? and how could a posted patch do that even ? [12:04:00 CEST] <cone-983> ffmpeg 03Bodecs Bela 07master:09a4853930e7: av_format/hlsenc: fix %v handling by format_name function [16:59:18 CEST] <durandal_1707> michaelni: Lynne left because of you [17:00:46 CEST] <BBB> ... [17:01:20 CEST] <BBB> I wish I had something meaningful to add here, but lately when I look at this tab in my IRC client, half of the time I see the same people arguing again and again [17:01:23 CEST] <BBB> this is getting really unhealthy [17:17:37 CEST] <kurosu> I have a bad view of the mailing list activity: is its activity getting worse or? Sure all the rage today is AV1, and so it happens elsewhere, but... [17:25:36 CEST] <jamrial> kurosu: the ml isn't too bad lately. but i think he's talking about michael's fuzzing related patches, many of which fix UB like integer overflows, and make the codebase somewhat uglier [17:25:52 CEST] <jamrial> some people have expressed their dislike for those [17:39:43 CEST] <michaelni> I wish these issues could be fixed in a prettier way but we need to fix them. leaving UB is not really an option [17:58:50 CEST] <kurosu> jamrial: Yeah, I wasn't particularly wondering about that particular instance, but more like if their proportion had increased [17:59:56 CEST] <kurosu> As for the particular instance, I bet it causes more happy users of the libs than developpers, indeed [20:00:45 CEST] <durandal_1707> michaelni: you are bad leader and developer, because you force your only solution upon others, you are dictator [20:38:58 CEST] <jamrial> durandal_1707: why do you feel the need to troll like this? [21:30:03 CEST] <jya> BtbN: any link to code I could look at? [21:31:11 CEST] <BtbN> All the stuff in fftools, primarily ffmpeg.c and its hw.c [21:31:15 CEST] <JEEB> for specifically vaapi there's a vaapi transcoding example which I have never tried [21:31:18 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/examples/vaapi_transcode… [21:31:27 CEST] <JEEB> but it seems to use the newer decoding API [21:31:30 CEST] <JEEB> with vaapi [21:35:29 CEST] <jya> JEEB: I'm happy to limit the code to a specific version of ffmpeg. [21:35:52 CEST] <jya> If that can convince people to finally update their machine, I'd be happy [21:36:21 CEST] Action: jya still have Libav 0.8 users with Ubuntu 12.04 [21:36:33 CEST] <JEEB> both the fftools command line tools and the example for vaapi transcoding should contain all the necessary stuff to get rolling with vaapi [21:36:43 CEST] <JEEB> so in that sense BtbN and me have given you the basic pointers :P [21:37:07 CEST] <JEEB> the example is shorter but I give no guarantees for it. you can attempt to compile it and see if it works as expected (it will decode and encode with vaapi) [21:37:12 CEST] <JEEB> and then look at the decoding part :P [21:37:24 CEST] <JEEB> then there's the fftools (ffmpeg.c etc) directory [21:37:32 CEST] <jya> I got a bit confused with the various examples on how to provide the vacontext structure info [21:37:33 CEST] <JEEB> which has the command line app's hwaccel implementation [21:37:39 CEST] <BtbN> I guess the primary issue for Firefox still is that hwdecoders output NV12 and the like? [21:37:48 CEST] <jya> Some example seem to indicate that this is now obsolete [21:38:08 CEST] <BtbN> All that plumbing moved to lavu, into the hwcontext and hwframes APIs [21:38:41 CEST] <JEEB> the example I linked includes hwcontext.h etc [21:38:45 CEST] <jya> Nv12 is not the problem. We are rolling our new webrender compositor. It has a unique shader requirement for all platforms [21:38:58 CEST] <jya> Write a single shader for use on all platforms. [21:39:12 CEST] <jya> And we have Nv12 support on Windows and Mac already [21:39:45 CEST] <JEEB> and it uses av_hwdevice_ctx_create(&hw_device_ctx, AV_HWDEVICE_TYPE_VAAPI, NULL, NULL, 0); [21:39:52 CEST] <JEEB> which I *think* is the newer way? [21:39:53 CEST] <JEEB> :P [21:40:15 CEST] <JEEB> so I would kind of recommend just taking a look at the decoding side of that example [21:40:41 CEST] <JEEB> and then asking more specific questions IFF you hit issues [21:53:44 CEST] <jya> JEEB: will do, thanks. [21:54:44 CEST] <jya> Iirc, in the original version from a vaapi surface Id you could map it to an opengl id. Is that still the case? [21:58:01 CEST] <electrotoscope> Hey, apologies for the newbie question, but what's the process for code posted to the ffmpeg-devel mailing list getting merged into the main code? [21:58:50 CEST] <JEEB> electrotoscope: it gets posted, then hopefully someone notices and has time to look at it [21:59:08 CEST] <JEEB> the patchwork link to the patch can also be ping'd here, and after a few days you can ping the actual patch on the mailing list [22:00:19 CEST] <electrotoscope> So that would be just responding to the thread and saying ping? This is the thread I'm curious about http://ffmpeg.org/pipermail/ffmpeg-devel/2019-June/245331.html [22:00:37 CEST] <electrotoscope> Don't want to be a nuisance but don't want it to get forgotten [22:03:04 CEST] <JEEB> bumping the version is basically the versions in a library's header [22:03:11 CEST] <JEEB> MAJOR.MINOR.MICRO [22:07:07 CEST] <electrotoscope> Would you say for this I should bump the Micro? [22:08:02 CEST] <JEEB> I don't remember the exact requirements for new features/options but the general documentation for developers should have that :P [22:08:38 CEST] <JEEB> > Depending on the change, you may need to change the version integer. Incrementing the first component means no backward compatibility to previous versions (e.g. removal of a function from the public API). Incrementing the second component means backward compatible change (e.g. addition of a function to the public API or extension of an existing data structure). Incrementing the third component means [22:08:44 CEST] <JEEB> a noteworthy binary compatible change (e.g. encoder bug fix that matters for the decoder). The third component always starts at 100 to distinguish FFmpeg from Libav. [22:08:47 CEST] <JEEB> from https://www.ffmpeg.org/developer.html [22:09:15 CEST] <JEEB> minor is usually done for new formats and codecs [22:11:08 CEST] <electrotoscope> Hmm okay cool cool [22:34:16 CEST] <electrotoscope> How do I find the library's header? like for vf_drawtext.c what would I be changing? [22:34:40 CEST] <JEEB> that's within libavfilter [22:35:05 CEST] <JEEB> and if you look at the list of .h headers there :P [22:35:06 CEST] <JEEB> libavfilter/avfilter.h [22:35:10 CEST] <electrotoscope> oh version.h? okay cool cool [22:35:13 CEST] <JEEB> or wait [22:35:14 CEST] <JEEB> version.h [22:35:18 CEST] <JEEB> yea :P probably that one [22:35:35 CEST] <electrotoscope> makes sense! [22:54:50 CEST] <electrotoscope> Remade patch, hopefully good now! http://ffmpeg.org/pipermail/ffmpeg-devel/2019-June/245567.html [22:54:51 CEST] <electrotoscope> Thanks!! [23:00:21 CEST] <durandal_1707> jamrial: i'm simply stating facts, you either ignore that or live in your own world [00:00:00 CEST] --- Thu Jun 20 2019

1 0

ffmpeg.log.20190619
by burek 20 Jun '19

20 Jun '19

[00:01:07 CEST] <furq> FlipFlops2001: it'll reduce the decoding speed [00:01:20 CEST] <furq> which is going to be a tiny fragment of the encoding speed but you might as well [00:01:29 CEST] <furq> also i'm not sure why you wouldn't just use libx265 from ffmpeg directly [00:31:07 CEST] <FlipFlops2001> @furq: I agree with the speed, but doesn't it allow x265 more processor time for encoding? My binary ver of x265 is 3.1_RC1+3 compiled with MSVC using Perfomance Guided Optimization (PGO). Don't you think this would be faster+having all the advantages and options of the new release candidate? [00:31:48 CEST] <FlipFlops2001> As opposed to using libx265? [02:57:23 CEST] <prowell> I have a video where the time_base in ((AVFormatContext*)formatContext)->streams[0]->time_base and (AVCodecContext*)context->time_base when decoding that stream don't match. Do they mean different things or is there some specific problem with the video that would cause this? The steam has a 90kHz rate while the codec context shows a 60Hz rate. [03:06:16 CEST] <nine_milli> say something balrog [03:06:25 CEST] <nine_milli> everywhere i go youre there [03:06:35 CEST] <balrog> Why [03:08:23 CEST] <nine_milli> you a street fighter fan? [05:06:28 CEST] <YellowOnion> how do I perverse the audio format during filtering, for sample reason it's converting pcmf32le to pcm_s16le [05:06:54 CEST] <furq> pastebin the full command and output [05:09:40 CEST] <YellowOnion> oh the plot thickens: https://gist.github.com/YellowOnion/7b486a30e5bbb1fe348cac795b14e7f5 [05:15:08 CEST] <furq> oh right [05:15:12 CEST] <furq> that has nothing to do with filtering [05:15:18 CEST] <furq> the default codec for wav is pcm_s16le [05:15:24 CEST] <furq> so -c:v pcm_s32le [05:15:28 CEST] <furq> or f32 rather [05:15:35 CEST] <furq> and -c:a rather [07:22:56 CEST] <grosso> change settings on-the-fly (while streaming rtmp): it is supported? [07:23:52 CEST] <grosso> I mean, while receiving rtmp stream, using the libraries [07:25:46 CEST] <grosso> suppose I'm receiving flv with h264/aac.. then the sender end changes video resolution (with and height) [07:26:22 CEST] <grosso> sometimes it works, sometimes it don't... when it works, I don't understand how [07:27:41 CEST] <grosso> same thing with ffplay, in fact [08:16:45 CEST] <mfwitten> How can I cut one stream down to the length of another? 'trim=end_frame=430' cuts a video shorter, but then how do I get ffmpeg to calculate where exactly to cut the associated audio stream? [08:18:41 CEST] <olavx200> How can i have the input and output files be the same and make ffmpeg overwrite the output file. [08:19:01 CEST] <mfwitten> olavx200: -y [08:19:42 CEST] <olavx200> ffmpeg -ss 5 -y -i "$FILE" "$FILE" [08:20:03 CEST] <olavx200> error: FFmpeg cannot edit existing files in-place. [08:20:10 CEST] <mfwitten> oh [08:20:51 CEST] <olavx200> i know i could copy "$FILE" to "$FILE"tmp and then do ffmpeg blablabla -i "$FILE" "$FILE"tmp but is there a more clean way to do this [08:22:01 CEST] <mfwitten> olavx200: What exactly is your purpose? [08:22:29 CEST] <mfwitten> olavx200: You just want to trim the file with as little calculation as possible? [08:23:06 CEST] <olavx200> yeah [08:23:25 CEST] <olavx200> i want to trim the intro music from a tutorial series i downloaded [08:25:04 CEST] <mfwitten> olavx200: Alas, you'd probably be fighting your file system, too, so I recommended dealing with a copy rather in-place [08:25:49 CEST] <olavx200> alright. [08:26:29 CEST] <olavx200> the videos are small so i though maybe it would be possible to load them into ram or something like that. [08:27:19 CEST] <mfwitten> olavx200: Well, if your temporary directory is RAM-based, then you could just copy the file to it [08:27:27 CEST] <olavx200> true [08:27:32 CEST] <Lyphe0> mfwitten: use the -shortest flag [08:28:01 CEST] <olavx200> anyway thanks for advice [08:28:27 CEST] <mfwitten> Lyphe0: Thanks for the idea, but that's an encoding/muxing option. I'm trying to build a complex filter graph where the streams are cut to size in the middle of filtering [08:28:39 CEST] <mfwitten> Lyphe0: So, encoding/muxing hasn't happened yet. [08:29:24 CEST] <mfwitten> Lyphe0: In other words, the `-shortest' option works if I allow myself to use an intermediate file to store the streams, but I don't want (or maybe can't) do that. [08:31:21 CEST] <mfwitten> Lyphe0: Maybe I could pipe the streams to another instance of ffmpeg, though.... [09:23:35 CEST] <mfwitten> Lyphe0: I did something liei the following and it worked: ffmpeg ... -shortest -c:a pcm_s32le -c:v rawvideo -f nut pipe:1 | ffmpeg -i pipe:0 ... [09:24:58 CEST] <mfwitten> Lyphe0: In my opinion, that sort of functionally should be available in the filter graph; maybe `concat' should be able to specify that each segment duration is determined by the shortest stream, for example. [09:44:31 CEST] <trashPanda_> Hello, I have a question regarding directing udp ffmpeg output to a particular NIC on windows 10. I used to use the format udp://[ip]:[port]/[NIC] but recently that has stopped working. Has anyone else noticed this? [09:48:00 CEST] <trashPanda_> For some reason it appears to just be using my windows routing table when I use this format, instead of going to the NIC I specify [09:55:57 CEST] <JEEB> not sure if that was ever properly supported? [09:56:12 CEST] <JEEB> and the URL options are really brittle [09:56:18 CEST] <JEEB> I would recommend utilizing the AVOptions [09:56:30 CEST] <JEEB> which through ffmpeg.c are just options [09:57:18 CEST] <trashPanda_> Could you explain that to me a little? Why is it brittle/not fully supported? And which AVOption are you talking about, a dictionary key/value? [10:06:34 CEST] <DHE> in source code you use the AVDictionary. on the cli tool, unknown "-key value" parameter pairs will be put into dictionaries to let whatever accepts them gobble them up [10:09:33 CEST] <trashPanda_> DHE, Thank you for that, I want to be able to do it in both places. In the CLI there are udp protocol options that I can set with ?localaddr=[NIC] and that works, but I need to be able to append pkt_size as well. The documentation says to use & to append the two, like ?localaddr=[NIC]&pkt_size=[size] but that isn't accepting the second param [10:12:01 CEST] <DHE> well there is the problem of a unix shell interpreting the & character [10:12:14 CEST] <trashPanda_> Im in windows cmd prompt [10:12:17 CEST] <DHE> but yes you can use -pkt_size 1316 -localaddr 192.168.0.3 udp://.... [10:12:39 CEST] <trashPanda_> interesting, ok I'll try that [10:17:33 CEST] <trashPanda_> that worked well, thank you [10:17:52 CEST] <trashPanda_> DHE, do you know where you pass the AVDictionary in for the source code? [10:22:35 CEST] <DHE> most of the *_open() or other initialization functions take it [15:12:27 CEST] <trashPanda_> Does anyone know where the output option "pkt_size" should be set on an output stream, I'm using the api. Ive tried setting the option on the output avctx with av_opt_set and in a dictionary thats passed to avformat_write_header but neither is working [16:25:54 CEST] <pk08> hi [16:26:32 CEST] <pk08> is there any way to use ffmpeg's filter_complex in ffplay [16:26:57 CEST] <pk08> i want to get volumebars over video so i am doing this by this command: https://pastebin.com/wdXYDNdH [16:27:47 CEST] <pk08> so if is there any way to play directly using ffplay without transcoding by ffmpeg,thn it will be very helpful [16:27:49 CEST] <pk08> thank you [16:43:05 CEST] <DHE> pk08: There's a little trick to video and audio filtering. they're still complex filters, with a default input label of [in] and a default output label of [out]. so you can just do -vf "[in]shenanigans;...;[d1][d2]overlay[out]" [16:44:32 CEST] <pk08> DHE: ffplay -f lavfi -i "udp://@235.1.1.118:374" -vf "[a]showvolume=w=w:h=w/12:o=1:f=0.50:r=25[vol0];[v][vol0]overlay=shortest=1:eval=0[out]" [16:44:35 CEST] <DHE> eg: play video at low resolution with an ugly green tint: ffplay VID_20161011_091524.mp4 -vf "[in]scale=320:240[scaled];color=c=green@0.5[red];[scaled][red]overlay[out]" [16:44:47 CEST] <pk08> using this command, i am getting No such filter: 'udp://' [16:45:41 CEST] <DHE> ah.... right, you need both audio and video. with -f lavfi it means that rather than a file you instead specify a full filter_complex string [16:46:17 CEST] <DHE> which can work with the filter "movie=..." but that gets messy quick, and I don't know if this would work with audio output as well [16:46:32 CEST] <DHE> TO THE MANUAL! [16:46:44 CEST] <pk08> i tried movie too! [16:46:49 CEST] <pk08> didnt get any luck [16:47:03 CEST] <DHE> well your colon will cause problems [16:47:21 CEST] <pk08> and i am not able to find more examples using ffplay [16:48:33 CEST] <pk08> DHE: its udp multicast to there will be colon :( [16:48:59 CEST] <DHE> just thinking into my keyboard: ffplay -f lavfi "movie=udp\\://236.1.1.118\\:374:s=dv+da[v][a];[a]showvolume=w=w:h=w/12:o=1:f=0.50:r=25[vol0];[v][vol0]overlay=shortest=1:eval=0[out]" [16:49:00 CEST] <pk08> so there* [16:49:44 CEST] <DHE> maybe leave out the [out] at the end... [16:50:29 CEST] <cehoyos> This looks strange:":s=dv+da" [16:50:54 CEST] <DHE> http://ffmpeg.org/ffmpeg-filters.html#movie [16:51:06 CEST] <DHE> otherwise the movie filter only outputs the video [16:51:25 CEST] <cehoyos> Thank you, just found it! [16:51:43 CEST] <cehoyos> lgtm [17:01:35 CEST] <pk08> ffplay -f lavfi "movie='udp\\://236.1.1.118\\:374':s=dv+da[v][a];[a]showvolume=w=w:h=w/12:o=1:f=0.50:r=25[vol0];[v][vol0]overlay=shortest=1:eval=0" [17:02:07 CEST] <pk08> with this command, i am not getting any error but not getting output too [17:03:22 CEST] <DHE> well I seem to have typo'd your multicast address [17:03:26 CEST] <DHE> that might be related [17:03:51 CEST] <pk08> no, i tried with different address [17:04:00 CEST] <pk08> address isnt the problem [17:05:08 CEST] <DHE> you're also both quoting and escaping the backslash.... [17:06:36 CEST] <pk08> if i dont quote [17:06:37 CEST] <pk08> Parsed_movie_0 @ 0x7f5b68001000] Failed to avformat_open_input 'udp' [17:06:38 CEST] <pk08> [lavfi @ 0x7f5b68009260] Error initializing filter 'movie' with args 'udp://239.1.1.1//:1234:s=dv+da' [17:06:38 CEST] <pk08> movie=udp\://239.1.1.1//:1234:s=dv+da[v][a];[v]scale=480x270[vout];[a]showvolume=w=480:h=20:o=1:f=0.50:r=25[vol0];[vout][vol0]overlay=shortest=1:eval=0: No such file or directory [17:06:47 CEST] <pk08> i am getting this error [17:21:46 CEST] <seanrdev> Hello. I'm just wondering if there is a way to limit the amount of RAM used with pulling rtsp streams using ffmpeg. [17:24:57 CEST] <ksk> I am not an experienced ffmpeg user, but I do not know about something like this [17:25:13 CEST] <ksk> seanrdev: might be cgroups etc can help you? put the ffmpeg into a memory-limited cgroup for example [17:26:00 CEST] <DHE> but if ffmpeg runs out of memory I would just assume it stops running [17:29:05 CEST] <ksk> totally possible, yes. [17:34:27 CEST] <trashPanda_> DHE, did you happen to see my question earlier about setting the options in C? I've tried throwing the pkt_size option into a few places and none of them have worked. [17:35:04 CEST] <DHE> i did' [17:36:39 CEST] <trashPanda_> any chance you know where the place to send it in would be? I'm honestly not sure where else would make sense to try and send it in other than the write_header or avctx [17:36:55 CEST] <DHE> I don't [17:37:06 CEST] <trashPanda_> Alright, thanks for your help [18:43:14 CEST] <aykroyd> is there a way to make ffplay listen to keyboard commands with the -nodisp switch enabled? i'm using it to listen to live HLS streams and want to quit without CTRL+C [18:43:52 CEST] <aykroyd> sample call: `ffplay -volume 9 -nodisp https://17963.live.streamtheworld.com/KBZTHD2AAC/HLS/playlist.m3u8` [18:45:30 CEST] <trashPanda_> DHE, just an fyi I figured it out. You can append it like the documentation says with the api, like udp://235.255.0.1:9000?pkt_size=1316&localaddr=192.168.1.12 and pass that whole string into avformat_alloc_output_context2 [18:46:06 CEST] <trashPanda_> so if you ever wanted to know or someone else asks, thanks for the help earlier : ) [18:55:34 CEST] <welcius> Hello, I have been googling for a while how to live transcode an http stream and output it to another http stream but no luck so far. Any idea of how can I do this? [19:06:45 CEST] <friendofafriend> welcius: ffmpeg -i <input> -c:a copy -c:v copy -f type <output> ? [19:07:33 CEST] <welcius> friendofafriend: output can be for example http://127.0.0.1:1234 ? [19:08:00 CEST] <friendofafriend> Sure, if you've got a server accepting connections from ffmpeg as a source. [19:08:20 CEST] <welcius> how can I do that? sorry its out of scope [19:08:44 CEST] <friendofafriend> You need a server that will do it. [19:10:32 CEST] <saml_> what codec and container are you using? [19:11:32 CEST] <saml_> if you're just copying, why do you run ffmpeg at all? just use input http:// ? [19:13:13 CEST] <friendofafriend> ffserver used to be the way to go for that, might try that mkvserver_mk2 thing. https://github.com/klaxa/mkvserver_mk2 [19:15:30 CEST] <saml_> This project is the result of years of thinking, trying and finally succeeding. [19:15:58 CEST] <friendofafriend> He didn't do it over coffee one morning. [19:45:55 CEST] <ChocolateArmpits> Anyone experienced keyframe timestamps given by ffprobe not really helping with keyframe accurate trimming for mp4 files? It somehow works with input ts files though. [20:25:01 CEST] <lavaflow> dumb question, but for a given codec, is `(vertical-resolution * horizontal-resolution) / average-bitrate` a reasonable metric by which to compare two different encodings of the same content? [20:25:50 CEST] <furq> if you divide by fps as well then that already is a metric (bits per pixel) [20:26:50 CEST] <furq> it's a good metric if you think the encoder used similar settings for both encodes [20:26:51 CEST] <lavaflow> ah right, fps too. does ffmpeg already calculate bits per pixel? or do I just calculate it myself? [20:26:58 CEST] <furq> mediainfo will show it [20:27:03 CEST] <lavaflow> nice, thanks [20:29:25 CEST] <furq> bpp is bitrate / (w*h*fps) [20:29:31 CEST] <furq> so not quite the same but the same sort of idea [20:29:42 CEST] <lavaflow> ah yeah, same principle [21:33:00 CEST] <mfwitten> I have 2 audio streams, each sampled at 48000 Hz; when I use either one by itself (and therefore throw out the other one), or even when I pass one through `amix=inputs=1' (which basically just passes it through), then everything is OK with using that one audio stream. However, if I attempt to mix the two streams into one stream (using `amix'), ffmpeg complains about bad DTS values: "Non-monotonous DTS in [21:33:06 CEST] <mfwitten> output stream 0:1; previous: 371000, current: -442721857768786551; changing to 371001..." Any ideas? Thanks! [21:34:15 CEST] <mfwitten> Each stream has 0 as its initial PTS (as set by `asetpts=PTS-STARTPTS', which is used after `atrim' for each stream). [21:36:43 CEST] <mfwitten> I get a bunch of those DTS errors. [21:45:48 CEST] <mfwitten> The "output stream 0:1" does indeed name the audio stream of the output file. [21:59:17 CEST] <mfwitten> Interstingly, the problem goes away when I save just the mixed audio rather than usign it as part of `concat'. Maybe ffmpeg doesn't handle a concat segment properly when the video stream is shorter than the audio. [22:18:08 CEST] <aykroyd> any ffplay experts? i'm wondering if i'm missing a config/setting or if i've got a bug tied with the -nodisp flag [22:18:53 CEST] <saml_> what's better vp9 or av1? [22:22:53 CEST] <kepstin> saml_: "it depends" [22:23:11 CEST] <mfwitten> saml_: av1, but the encoder is currently too slow to be practical. VP9 is great, but there are a lot of devices that don't play it. Then again, Windows doesn't play H.264 out-of-the-box either. In truth, nothing works; A/V is a giant hack. [22:24:47 CEST] <mfwitten> kepstin: Still a major problem: https://trac.ffmpeg.org/ticket/7716 [22:30:16 CEST] <saml_> every device plays av1 natively right? [22:32:49 CEST] <mfwitten> saml_: No [22:57:08 CEST] <mfwitten> Well, now ffmpeg is giving me a segfault just because I swapped the order of concat segments. You know... this tool has promise, and I've done some interesting things with it, but it's just too buggy. If anyone cares to hear my advice, it is this: re-write ffmpeg with clean-room principles, from the ground up, with correctness and consistency as a major goal. [22:57:16 CEST] <mfwitten> So long, and thanks for for all the fish! [23:00:53 CEST] <furq> good advice [23:01:15 CEST] <c_14> did anyone ask him what version he was running? [23:01:20 CEST] <c_14> if it's segfaulting it's probably not new enough [23:01:41 CEST] <durandal_1707> noone carse for fake users [23:01:57 CEST] <furq> i love telling people working on a project that was started in 2000 that "this tool has promise" [23:02:25 CEST] <furq> maybe some day some major corporations will have their entire backend based on this promising upstart tool [23:03:35 CEST] <durandal_1707> furq: what is your point? [23:08:28 CEST] <durandal_1707> trollers are not welcomed here [00:00:00 CEST] --- Thu Jun 20 2019

1 0

ffmpeg-devel.log.20190618
by burek 19 Jun '19

19 Jun '19

[00:56:50 CEST] <cone-655> ffmpeg 03Jun Zhao 07release/4.1:72f03b2af489: lavc/libaomenc: Add a maximum constraint of 64 encoder threads. [04:54:56 CEST] <cone-866> ffmpeg 03Limin Wang 07master:268ab17c519f: libavcodec/videotoolboxenc: Fix compilation broken on macOS 10.12 [12:31:09 CEST] <faeez> Hi, I am planning on adding support to set different PID's to audio and video streams via AVOptions. Direction on how to would be much appreciated [12:31:22 CEST] <faeez> In mpegTS [12:36:15 CEST] <funman> faeez: you can already set AVStream->id no ? [12:38:05 CEST] <faeez> Not sure of that, as I want to expose the option to the user without making any changes in fftools, I am planning on just making changes in mpegtsenc.c [12:38:53 CEST] <faeez> also I want to expose few other cutomized options [12:43:14 CEST] <funman> ffmpeg -i foo.ts -vc copy -acodec copy -streamid 0:42 -streamid 1:444 test.ts [12:51:44 CEST] <faeez> Thanks funman [12:55:43 CEST] <faeez> How about handling multiple program, setting different PCR PID, PMTPID, managing time between PCRs for each program [13:04:32 CEST] <funman> there is an option for pmt pid already [13:07:41 CEST] <faeez> I am assuming you are suggesting 'mpegts_pmt_start_pid'. My intention is to provide exclusive control to user to set different pmt PID's for each program. [13:08:16 CEST] <faeez> mpegts_pmt_start_pid only allows to set the first pid of pmt [13:10:13 CEST] <funman> yes that's the one i saw [13:12:03 CEST] <faeez> Are you aware of anyway to have dynamic array for setting avoptions? [13:13:11 CEST] <funman> no [13:13:12 CEST] <faeez> other then OptionDef exposed by ffmpeg_opt.c [13:14:55 CEST] <faeez> Appreciate your time [15:24:00 CEST] <cone-045> ffmpeg 03Gyan Doshi 07master:2fdbeb0b8cc3: avformat/segment: fix increment_tc [15:59:22 CEST] <mkver> jkqxz: I am currently rebasing the old patchset to update the AVCodecParameters with the *_metadata filters. Do you want them to be updated optionally (but by default) or should it be done totally automatically (as James suggested)? [17:29:00 CEST] <cone-045> ffmpeg 03Jun Zhao 07master:ebcf4d354f5c: lavfi/af_asetnsamples: Remove the redundant condition check [22:41:09 CEST] <Marshalleq> Hello, I have read that ffmpeg becomes less efficient as you add more cores. Is this still the case in 2019? If so how many cores per ffmpeg instance would be optimum? [22:49:08 CEST] <durandal_1707> Marshalleq: where have you read that lie? [22:50:11 CEST] <Marshalleq> durandal_1707 I'll see if I can ferret it out - I couldn't find anything that said otherwise, so I thought I'd ask here. [22:50:17 CEST] <JEEB> well we do say that if you set AVCodecContext's threads to over 16 that it is not recommend etc etc [22:50:29 CEST] <JEEB> although you can still set it much much higher [22:50:39 CEST] <JEEB> granted, it might not be efficient in many ways :P [22:51:16 CEST] <JEEB> but saying taht FFmpeg in general would become less efficient... less true. since in many cases you are running more than one thing [22:51:35 CEST] <JEEB> so you can run your decoder with X threads, then filtering, then encoding or multiple encoders [22:51:49 CEST] <JEEB> all of those generally can have N>=1 threads [23:04:07 CEST] <Marshalleq> Thanks. So other question, I'm running on two AMD systems TR 1950X and Ryzen 1850X - The Threadripper runs KVM/XEN Virtualisation and has various emulation modes that can be presented to the VM. I haven't found a list of what CPU extensions ffmpeg uses, so that I can understand what performance hit might be present if running virtualised in e.g. Q35-3.1. Is there a list anywhere? [00:00:00 CEST] --- Wed Jun 19 2019

1 0

ffmpeg.log.20190618
by burek 19 Jun '19

19 Jun '19

[00:29:47 CEST] <SoMuchForSubtlet> kepstin: I got my script working "found desired audio at index 2 and best video at index 12" [03:21:53 CEST] <pa[m]> OK, I just tried for way too long to figure out how to use ffmpeg to go from sRGB to Rec 709. Attempted on a grayscale, linear gradient, just to focus on the gamma. There does not seem to be any filter that gives a result comparable to AE or Fusion. [03:23:04 CEST] <pa[m]> by 'any filter' i mean i tried swscale, colormatrix and colorspace [07:02:40 CEST] <friendofafriend> I see there's no way to mux h265 into an FLV for RTMP streaming. Can someone recommend another protocol to use instead? [07:30:09 CEST] <kepstin> what are you streaming too? (what's gonna play it?) [10:55:39 CEST] <realies> can you pipe raw h264 to fffmpeg and pipe it into nc with a streamable container? [12:45:44 CEST] <DHE> realies: I dont' see why not... just a matter of selecting a streamable container. but I'd like to point out ffmpeg can output to tcp or udp itself as well, no NC required [14:10:17 CEST] <TypX> Hi, I'm a little confused by doc/examples/filtering_audio.c [14:10:46 CEST] <TypX> why is the abffer set in the output AVFilterInOut [14:11:02 CEST] <TypX> and abuffersink in the input AVFilterInOut? [14:21:22 CEST] <JEEB> TypX: I think those are meta'ish filters [14:21:32 CEST] <JEEB> doc/examples/filter_audio.c: * (input) -> abuffer -> volume -> aformat -> abuffersink -> (output) [14:21:36 CEST] <JEEB> doc/examples/filter_audio.c: * abuffer: This provides the endpoint where you can feed the decoded samples. [14:21:39 CEST] <JEEB> doc/examples/filter_audio.c: * abuffersink: This provides the endpoint where you can read the samples afte [14:21:58 CEST] <TypX> JEEB: oh indeed [14:22:02 CEST] <TypX> thanks [14:25:12 CEST] <JEEB> I have some code of my own where I init those two first, then start building the chain so that the abuffersink gets linked at the end [14:26:04 CEST] <JEEB> also avfilter_graph_dump() can be useful for debugging [14:26:25 CEST] <JEEB> together with avfilter_graph_set_auto_convert(filter_graph, AVFILTER_AUTO_CONVERT_NONE) [14:26:28 CEST] <JEEB> :) [14:27:06 CEST] <JEEB> of course the latter means that you have to insert an aresample filter manually into the chain [14:27:20 CEST] <JEEB> but it also means that lavfi will not automagically insert random stuff into the chain when it feels like it :) [14:29:01 CEST] <DHE> I suspect 'output' and 'input' are meant to be relative to the program interacting with the filter rather than the filter itself. you interact with the [a]buffer[sink] objects, not really the filtergraph itself [14:29:38 CEST] <JEEB> yes [14:51:05 CEST] <DisgruntledCoder> hi there, is it possible with FFmpeg to get the specific channel mapping (in terms of L R C LFE LS RS etc...) of a given file, beyond what 'channel_layout' returns (which seems to be either wrong or just not meant to contain that info)? [14:54:48 CEST] Action: DisgruntledCoder channels JEEB :D [15:13:49 CEST] <Spaligor> hi guys [15:15:07 CEST] <Spaligor> i need help, i'm trying to keep keep a stream buffer of last 5 minutes recorded from a camera [15:15:39 CEST] <Spaligor> how can i do it? i've read about circular buffer and even did some of it by segmenting ecc [15:15:57 CEST] <Spaligor> but there's a way to keep this 5 minutes recording and then save it to a file? [15:25:54 CEST] <DHE> and he's gone [15:28:15 CEST] <friendofafriend> I'd love a recommendation of an RTSP server. I'm streaming a few h265 camera streams to my friend and a smartphone once in a while. Is live555 the way to go? [15:30:59 CEST] <ksk> friendofafriend: I dont really know what RTSP nor RTMP actually are, but you can convert one to the other and combine that with nginx from looking at the webz ;) [15:31:56 CEST] <GuiToris> hey, how can I make a 25fps video from a 50fps video? ffmpeg -framerate 50 -i seq_%3d.png -framerate 25 output.mp4 didn't do the trick [15:32:31 CEST] <ksk> GuiToris: just a quess: remove the "-framerate 50" argument? [15:32:34 CEST] <ksk> guess* [15:33:00 CEST] <GuiToris> the first one supposed to be the input framerate [15:33:08 CEST] <friendofafriend> ksk: RTMP won't support h265 in an FLV container, it's an Adobe thing. [15:33:22 CEST] <ksk> is that how ffmpeg works GuiToris? I am really a noob, but I am inclined to say no ;) [15:33:34 CEST] <ksk> friendofafriend: ah okay. thanks. [15:33:59 CEST] <GuiToris> ksk: yes?! [15:35:00 CEST] <friendofafriend> GuiToris: Do you want to drop frames, or a video that runs at half speed? [15:35:12 CEST] <GuiToris> friendofafriend, drop every other frame [15:35:24 CEST] <GuiToris> the speed should stay the same [15:35:54 CEST] <friendofafriend> GuiToris: ffmpeg -i <input> -filter:v fps=fps=25 <output> [15:36:15 CEST] <ksk> GuiToris: so it rather seems "no!?" :P [15:36:24 CEST] <GuiToris> ksk, please [15:39:07 CEST] <GuiToris> thank you it works friendofafriend [15:39:18 CEST] <GuiToris> ksk, I need the first -framerate 50 because my source is not a video [15:39:32 CEST] <friendofafriend> Always welcome, GuiToris. Glad to hear it. [16:00:30 CEST] <Ristovski> Any idea why kmsgrab seems to cause weird color issues when encoding with VAAPI? [16:00:42 CEST] <Ristovski> (normal encoding is broken, so can't test if it's specific to VAAPI) [16:00:59 CEST] <Ristovski> Currently running ` ffmpeg -threads:v 2 -framerate 60 -f kmsgrab -i - -vf 'hwmap=derive_device=vaapi,scale_vaapi=w=1366:h=768:format=nv12' -c:v h264_vaapi -profile:v high -bf 0 -y output.mp4` [16:01:17 CEST] <Ristovski> which works very well but it seems to mess certain colors, maybe because of the bgr0 format [16:03:41 CEST] <Ristovski> It seems to "smear" colors, black/white text is text perfect but anything that has colors appears fuzzy [16:04:34 CEST] <Ristovski> screenshot: https://pybin.pw/gDwf.png recording: https://pybin.pw/ctcS.png [16:09:15 CEST] <durandal_1707> DisgruntledCoder: channelmap filter [16:23:36 CEST] <kepstin> Ristovski: that's just a side-effect of the conversion to 4:2:0 sampling, it has less color resolution [16:23:57 CEST] <Ristovski> kepstin: Ah, that sucks :/ [16:24:07 CEST] <Ristovski> kmsgrab indeed has almost no performance overhead [16:24:09 CEST] <kepstin> totally expected. And your hardware encoder probably can't do 4:4:4, so if you want to avoid that you'd have to do software encoding. [16:24:49 CEST] <Ristovski> x11grab works fine but not as efficient as kmsgrab [16:25:10 CEST] <kepstin> x11grab vs kmsgrab won't make a difference in terms of this issue [16:25:26 CEST] <Ristovski> Well it does for me, x11 grab has no such issues [16:26:10 CEST] <kepstin> Ristovski: you must be using a different encoder or other different options then, because it's the conversion to 4:2:0 sampling that causes the issue [16:26:35 CEST] <kepstin> note that libx264 (software encoder) can do 4:4:4 sampling which avoids the issue - but is less compatible with players. [16:27:01 CEST] <Ristovski> `ffmpeg -init_hw_device vaapi=foo:/dev/dri/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -hwaccel_device foo -f x11grab -framerate 60 -video_size 1366x768 -i :0.0 -filter_hw_device foo -vf 'format=nv12|vaapi,hwupload' -c:v h264_vaapi -y output.mp4` [16:27:14 CEST] <Ristovski> Seems pretty standard to me [16:27:18 CEST] <Ristovski> and it works just fine [16:27:56 CEST] <kepstin> i'd expect the exact same results from that, huh. [16:28:28 CEST] <kepstin> if you could maybe give a screenshot of the issue? it could be something different from what I'm thinking it is. [16:28:48 CEST] <furq> i assume it's the colours rather than the blurry text [16:28:52 CEST] <Ristovski> furq: yes [16:29:02 CEST] <Ristovski> Stuff like cyan appears as white [16:29:23 CEST] <kepstin> oh, you're actually getting *wrong* colors, not *blurry* colors? [16:29:30 CEST] <furq> i would guess scale_vaapi is just doing a shitty job of the rgb to yuv conversion [16:29:37 CEST] <Ristovski> kepstin: well they are also blurry [16:29:40 CEST] <furq> there's nothing else in that pipeline that could be to blame [16:29:48 CEST] <furq> and yeah the blurriness is just going to happen. there's nothing you can do about that [16:29:53 CEST] <kepstin> Ristovski: blurry is normal and expected, wrong is an issue. [16:30:06 CEST] <Ristovski> kepstin: kmsgrab also produces a severely darker recording [16:30:20 CEST] <Ristovski> furq: doesn't x11grab also do rgb to yuv? [16:30:37 CEST] <furq> no and neither does kmsgrab [16:31:21 CEST] <Ristovski> Let me try getting a better screenshot [16:31:22 CEST] <kepstin> Ristovski: it would be good to try using kmsgrab to grab a single frame as png and see if it shows the same problem. [16:31:28 CEST] <furq> yeah [16:31:37 CEST] <kepstin> (or, i missed the screenshots originally, oops) [16:31:52 CEST] <furq> well i assume one is print screen which isn't the same as what kmsgrab is outputting [16:32:18 CEST] <furq> like i said i assume it's scale_vaapi but if you're running x11grab and scale_vaapi and it works then i have no idea [16:32:20 CEST] <kepstin> that looks like chroma samples in the wrong location, tbh [16:33:27 CEST] <kepstin> but that said, a single pixel width line of yellow over blue is impossible to represent in yuv 4:2:0 sampling [16:33:31 CEST] <kepstin> so... :/ [16:33:47 CEST] <Ristovski> Hmm, when I do kmsgrab to get a png, OR when using kmsgrab with software encoding I get a pixel soup - https://pybin.pw/K52L.png [16:34:30 CEST] <Ristovski> however, judging from the colors of the pixels (lol) it does appear to be fine [16:35:07 CEST] <kepstin> yeah, so looks like an issue from the rgb to yuv 4:2:0 sampling. Avoid brightly colored single-pixel-wide lines, especially over backgrounds of different colors, and it'll be fine. [16:35:51 CEST] <kepstin> that said it also looks like there's a color range issue, it's not properly converting from pc (full) range to video (limited) range [16:36:10 CEST] <Ristovski> What about the weird corruption? [16:36:17 CEST] <kepstin> dunno about that :/ [16:36:54 CEST] <Ristovski> I mean, odd that it works when encoding via vaapi [16:38:41 CEST] <kepstin> anyways, if you're getting better results with that x11grab command instead of the kmsgrab one, it's probably because in the x11grab one the rgb to yuv conversion is done on the cpu in ffmpeg with a better algorithm :/ [16:39:39 CEST] <Ristovski> Hmm, the kmsgrab with corruption indeed seems to be perfect apart from the weird corruption [16:44:22 CEST] <Ristovski> furq: and yes, x11grab with scale_vaapi works fine [16:46:12 CEST] <Ristovski> here's a debug log of kmsgrab capturing a single frame which causes the corruption - https://bpaste.net/show/b3e090faf293 [17:14:18 CEST] <TheAMM> I'm not in the position to test this right now, so I have to ask instead: does -pass 1/2 work for libx265 instead of having to use -x265-params pass1/2? [17:19:01 CEST] <kepstin> TheAMM: no, it's not wired up. [17:32:23 CEST] <ncouloute> So I narrowed down my frame shifting issue is due to using the hwaccel qsv decoder. It was causing the 4 frame shift. Any flags that will fix that? When I use software decode I lose frames. So thats another issue that [18:39:35 CEST] <ncouloute> For the software decoder. It only decodes 16093 of 16200 of the frames. One of the errors I see is. Application provided invalid, non monotonically increasing dts to muxer in stream 0: 2865>= 2865. I do notice that there appears to be a few frames of video of a future part of the video that plays inbetween each "clip". The HW decoders will decode all the frames properly. Any ideas? [18:43:30 CEST] <JEEB> are you sure you are counting decoded frames? [18:43:40 CEST] <JEEB> since that message comes from the muxer, not decode [18:43:42 CEST] <JEEB> *decoder [18:56:55 CEST] <blloyd> I am using libavcodec and friends from ffmpeg 4.1.3 to decode a h264 stream. I am getting frequent invalid NAL errors. Is there a way to continue decoding that frame or do I have to start on the next packet? It seems after an error, the parser gets stuck in a near infinite loop just consuming bytes without outputting another frame. [18:59:05 CEST] <ncouloute> I'm going off the frame=xxx after ffmpeg is done and what media info reports for both the container and the video stream. On the converted file it freezes frame until the next clip versus the original which plays a few frames of video from different part of the file. [19:03:28 CEST] <JEEB> ffmpeg -vsync passthrough -v verbose -i FILE -map 0:v -f null - [19:03:32 CEST] <JEEB> this should decode only [19:03:41 CEST] <JEEB> through the ffmpeg.c command line app [19:07:25 CEST] <ncouloute> okay let me try that [19:18:01 CEST] <ncouloute> Here is what is says for input: 16200 packets read (650416459 bytes); 16093 frames decoded; Total: 16200 packets (650416459 bytes) demuxed [19:36:46 CEST] <TheAMM> Have you determined you actually lose *frames*? [19:37:04 CEST] <TheAMM> IIRC something something h264 frames can sometimes be spread over two packets [19:38:00 CEST] <TheAMM> something about fields, saw mention of it in vapoursynth sources [19:40:00 CEST] <ncouloute> I am losing frames.. but it is technically the same frames that are in different parts of the video. In those area of the converted files the video itself just shows the same frame for 3 seconds. Hopefully that makes sense [19:41:15 CEST] <JEEB> what have you verified against that the stream is as passed decode'able A->B, just out of curiosity [19:41:27 CEST] <JEEB> also is anything funky like field duplication being utilized [19:45:28 CEST] <ncouloute> Not sure I know what you mean by the first part but the Original file is VFR and Interlaced (Separated Fields, TFF). So there could be something going on with the built in deinterlacer. The HW decoders(cuvid\qsv) seem to decode it correctly but it has other issues like frames being shifted [20:29:20 CEST] <pa[m]> anyone know if it's possible to embed an icc profile name in a quicktime mov, such that Adobe programs understand what color space it's in? [20:32:34 CEST] <JEEB> qtff documentation is probably your best bet regarding that [20:32:55 CEST] <JEEB> https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/ [20:35:46 CEST] <JEEB> ok, seems like mov files output in QTIF (quicktime image) format have an iicc atom [20:38:53 CEST] <saml_> is per video encoding parameter optimization worth effort? [20:39:25 CEST] <saml_> given a video, find out the best ffmpeg arguments for that particular video [20:52:56 CEST] <JEEB> latter sets the encoder's AVCodecContext to that, while if I understand setparams correctly it just sets the outgoing AVFrames' primaries to that [20:53:21 CEST] <JEEB> a lot of encoders initialize when the encoder is initialized, so only the AVCodecContext part would get applied [20:53:30 CEST] <JEEB> (if the encoder utilizes that value) [20:53:49 CEST] <JEEB> in theory an encoder wrapper could wait until the first AVFrame is fed to it [20:53:59 CEST] <JEEB> and would configure itself accordingly [20:55:43 CEST] <JEEB> there's functionality in the libx264 wrapper to re-configure when some paramters change in the input AVFrames, but even after patching x264 a bit I never got that stuff to be applied with colorspace info. but I probably just failed at life / PEBKAC :P [20:56:21 CEST] <JEEB> if I ever have the time again I might look into that again, but even when it seemed like you hit the "please reconfigure" switch it would still not do it [20:56:38 CEST] <JEEB> (and this was before any pictures were fed to the encoder, so in theory the following picture would have been a random access point) [20:57:01 CEST] <JEEB> which is the main thing that people talk about, that the configuration might get applied later [21:13:25 CEST] <__Shepherd> this guy is trying to decode a ".axxc" file [21:13:46 CEST] <ncouloute> It is not so much that I'm worried about the frames lost as there. It is that the timing is also thrown off as a result. I guess I should play around with the *synth programs and see if I can get them to decode it properly then pass that on to ffmpeg. I deal with a lot of garbage video.. so that may be the only way to convert it [21:14:13 CEST] <__Shepherd> apparently it an encrypted audio file [21:14:58 CEST] <__Shepherd> so gotta provide a key when passing it to ffmpeg [21:15:47 CEST] <__Shepherd> he's got errors doing a stream copy [21:15:57 CEST] <__Shepherd> looking at his log [21:17:03 CEST] <__Shepherd> his decoding is stuck at the first frame and has outputed about 20MB of data... on the very first frame [21:18:16 CEST] <__Shepherd> I had an issue like this in the past with an flv container but can't remember what was it that I did to fix that issue [21:20:19 CEST] <__Shepherd> https://www.reddit.com/r/ffmpeg/comments/c21nxt/convert_axxc_format/ [22:35:28 CEST] <SortaCore> hey fellas [22:35:50 CEST] <SortaCore> anyone know password-protected video codecs/container codecs? will be played back on Windoze [23:21:35 CEST] <SortaCore> back in a bit, compy needs to reboto [23:47:38 CEST] <FlipFlops2001> I've been re-encoding my videos to the h.265 format using ffmpeg piped to x265. Is there any advantage to "-hwaccel dxva2" or "-hwaccel auto" in this process? (Video processor: AMD 6670 supports DXVA2) [00:00:00 CEST] --- Wed Jun 19 2019

1 0

ffmpeg-devel.log.20190617
by burek 18 Jun '19

18 Jun '19

[09:37:23 CEST] <j-b> yo [09:39:50 CEST] <durandal_1707> xo [13:28:15 CEST] <cone-288> ffmpeg 03Gyan Doshi 07master:756dd9812028: doc/filters: correct typos in tinterlace flags [15:58:29 CEST] <stuartm> nevcairiel: Thanks for the response. [16:46:35 CEST] <mkver> jamrial: Thanks for reviewing my latest patchset. But does not answering to a patch imply a LGTM from you? (And how does it come that you are sometimes listed as op and sometimes not?) [16:49:05 CEST] <jamrial> mkver: i don't always log in with nickserv [16:50:50 CEST] <jamrial> and no, no reply doesn't imply lgtm [17:19:59 CEST] <qacky> Maybe a dumb question but can anyone explain the logic behind the frame sequence check in fftools/ffmpeg.c::write_packet()? The comment only notes audio encoders as a possible source but that isn't the case at all. It's quite possible (and happens a lot), for networks to cause them too for example. I have a local patch to remove the check because it causes studdering but it's not ideal.. which [17:20:05 CEST] <qacky> would be buffering for some short period and try to recover. [17:20:35 CEST] <qacky> The packets aren't lost, just delayed and sometimes not even that, they are identical. [00:00:00 CEST] --- Tue Jun 18 2019

1 0

ffmpeg.log.20190617
by burek 18 Jun '19

18 Jun '19

[00:14:31 CEST] <void09> where I can I see some refference psnr and ssim and such scores for encoders? [00:16:49 CEST] <kepstin> void09: there's not really any such thing? the numbers vary so much between encoder options and even over time as encoders develop... [00:17:31 CEST] <void09> I did those tests for my encodes.. but I have no idea what they mean [00:17:53 CEST] <void09> PSNR score = 48.584059 SSIM score = 0.997152 [00:17:54 CEST] <kepstin> modern encoders typically even have psnr/ssim optimizations that make the scores higher but potentially reduce perceptual quality [00:18:25 CEST] <void09> is that "good" ? :) [00:18:59 CEST] <kepstin> void09: the numbers are only really useful in comparison to other numbers [00:19:15 CEST] <kepstin> so if you do two encodes and compare the psnr, you can see that one encode has better psnr than another [00:19:31 CEST] <kepstin> which may or may not correspond to one encode looking better than another [00:19:32 CEST] <void09> yeah i did two encodes, one with 8 bit encode, the other with 10bit , of the same 8 bit source [00:19:41 CEST] <void09> 10bit one has lower scores yet it appears to look better to me [00:21:20 CEST] <kepstin> presumably you had to convert the 10bit back to 8bit to do the psnr comparison, and that usually involves dither, which is literally adding noise [00:21:31 CEST] <kepstin> so, yeah. [00:23:13 CEST] <kepstin> if you think the 10bit looks better why are you even bothering to measure anyways? looking better to you is the thing that matters in the end. [00:23:27 CEST] <void09> somebody asked me to [00:23:34 CEST] <void09> but I am not an expert. [00:24:36 CEST] <void09> can't really tell much difference except the 10bit one suffers from minimal colour banding, whereas in the 8bit one it is rather obvious in a certain part of the video [00:25:23 CEST] <void09> so that's why the lower scores.. 10bit to 8bit to do comparison with the 8bit source, which involves dither ? [00:25:27 CEST] <void09> this is the ffmpeg line i used [00:25:47 CEST] <void09> ffmpeg -i 10bit-257.mkv -i 4244frameBluray.mkv -lavfi libvmaf="psnr=1:ssim=1:ms_ssim=1" -f null - [00:27:06 CEST] <kepstin> yeah, you can't compute the comparisons between different bit depths, so one or the other would have to be converted. hard to say what exactly the numbers mean in that circumstance [00:27:20 CEST] <void09> hm true.. [00:27:31 CEST] <void09> but which one was converted to which ? [00:27:40 CEST] <void09> what if the source was converted to 10bit ? [00:27:50 CEST] <kepstin> would need to see that command run with -v verbose to see the auto-inserted conversions to confirm [00:27:58 CEST] <kepstin> but it probably upconverted the source to 10bit [00:28:11 CEST] <void09> but even then, you'd have a slightly different colour spectrum I presume [00:28:28 CEST] <void09> the encode was done with constant quality, so they should be about the same quality [00:28:41 CEST] <kepstin> what encoder? x264? [00:28:43 CEST] <void09> the 10bit one turned out 4% smaller [00:28:44 CEST] <void09> no, av1 [00:29:00 CEST] <kepstin> hmm, i know nothing about av1 encoders [00:29:13 CEST] <kepstin> but in other encoders the constant quality modes aren't comparable between bitrates [00:29:20 CEST] <kepstin> i'd expect most av1 encoders to be similar [00:29:41 CEST] <kepstin> aren't comparable between bit depths* [00:30:16 CEST] <void09> right. [00:30:27 CEST] <void09> testing with another av1 yielded a much larger file for 10bit [00:30:33 CEST] <kepstin> anyways, for actual playback that a person would see, the 10bit video is typically downconverted to 8bit and dithered - since 10bit displays are currently very rare [00:30:50 CEST] <void09> hm I should get one [00:30:59 CEST] <void09> just for this purpose :) [00:31:37 CEST] <void09> who does that dithering? [00:31:41 CEST] <void09> when playing a 10bit file [00:31:50 CEST] <void09> where does it happen [00:32:17 CEST] <kepstin> typically video player [00:33:01 CEST] <kepstin> e.g. mpv has 8-to-10bit conversion with dither as part of the yuv to rgb conversion that it uses for pc playback, and that runs on gpu shaders on supported machines. [00:36:48 CEST] <kepstin> it's looking like most 10bit+ consumer displays are gonna be hdr displays with expanded color space, so i doubt they'd be capable of playback of 10bit non-hdr video anyways. [00:37:15 CEST] <void09> i thought hdr was 10bit [00:37:39 CEST] <void09> or does hdr need at least 10bit [00:37:53 CEST] <kepstin> hdr and 10bit are orthagonal. it's just that since hdr uses a wider brightness range, you get really bad banding unless you increase the bit depth [00:39:44 CEST] <void09> how does one find true 10 bit displays? [00:40:17 CEST] <void09> as in, not the ones that use that pixel flashing trick to simulate extra colorus [00:41:01 CEST] <kepstin> i dunno, i've never seen once. I suspect they're mostly sold for stuff like medical imaging? [00:41:36 CEST] <kepstin> it's kind of surprising how few displays are actually 8-bit, there's a lot of low end monitors that are really 6bit :) [00:47:35 CEST] <kepstin> interesting, the vesa displayhdr specs requires that monitors accept 10bit signals and do 10bit processing, but allows them to use 8bit panels with dithering. [00:49:11 CEST] <der_richter> use your comparison shopping site of your choice and filter for 10bit without FRC, i guess [00:51:18 CEST] <der_richter> https://skinflint.co.uk/?cat=monlcd19wide&xf=11959_10bit+(10bit+ohne+FRC)&s… [00:52:55 CEST] <kepstin> hmm, i doubt that actually worked, i'm pretty sure most of the cheaper monitors in that list are 8bit panels without mentioning frc :) [00:52:55 CEST] <void09> I doubt that filtering produces accurate results. It's only as good as the entries are complete/correct in the database [00:53:00 CEST] <void09> lol [00:53:06 CEST] <der_richter> they are [00:53:43 CEST] <der_richter> but really someone who is looking for quality and buys a dead cheap monitor... [00:54:18 CEST] <der_richter> it help weeding out a lot of the shit at least and one can cross check some of the more expensive ones with other sources [00:54:30 CEST] <void09> https://skinflint.co.uk/dell-ultrasharp-up3216q-210-aguo-210-agur-a1329898.… [00:54:41 CEST] <void09> this one is :) 10bit (10bit without FRC). so they actually exist [00:55:45 CEST] <void09> https://skinflint.co.uk/iiyama-prolite-xu2395wsu-b1-a1853295.html?hloc=uk [00:55:52 CEST] <void09> but this one says the same.. 10bit with no frc [00:56:26 CEST] <der_richter> >expecting a dead cheap display to...< [00:56:51 CEST] <der_richter> obviously it needs some commong sense [00:56:58 CEST] <kepstin> note that you might need to also get a high end professional graphics card (e.g. quadro or radeon pro) to get driver support to output 10bit to the monitor - although that'll hopefully change soon for consumer hdr monitors. [00:57:46 CEST] <der_richter> https://skinflint.co.uk/samsung-u32h850-lu32h850umuxen-a1622028.html?hloc=uk i believe this one is also 10bit without frc [00:58:16 CEST] <void09> what, no 10bit output on high end gaming gpus ? ;o [00:58:40 CEST] <kepstin> in older generations it was arbitrarily driver limited :/ [00:59:10 CEST] <void09> oh, a driver limitation [01:03:18 CEST] <kepstin> but yeah, note that these hdr monitors map the 10bit to a wider color range - so for playing non-hdr video, it's won't use the full color range of the monitor, which means it's not making full use of the extra bit depth :) should still be better than 8bit tho. [01:03:59 CEST] <kepstin> unless you don't have it color managed properly - in which case it will use the full range of the monitor, and the video will look too contrasty and saturated. [05:50:30 CEST] <kebabas> hello anyone here? [05:51:21 CEST] <kebabas> im encoding hevc hdr video to dnxhr 444 but im losing hdr settings. Im using command line like this: ffmpeg -i input.mkv -c:v dnxhd -vf "scale=4096:2160,fps=30000/1001,format=yuv444p10le" -profile:v dnxhr_444 outputas.mov [05:51:44 CEST] <kebabas> is here any way to make it dnxhr hdr? because original content is in hdr [06:10:27 CEST] <kebabas> Hey @Buster maybe you can help me with ffmpeg? [13:07:06 CEST] <urdne> hello fellows, i'm trying to batch convert some videos from vp8 to mp4 on windows and the tactic of googling for what to copy/paste has led me to several deadends. any assistance? https://pastebin.com/3mcwdkvB [13:07:38 CEST] <urdne> i figured it would be as simple as changing filename.webm filename.mp4 to *.webm *.mp4 but alas, nothing ever is, is it [13:14:53 CEST] <c_14> urdne: try adding -c:v libx264 [13:15:22 CEST] <c_14> I'm not entirely sure why, but it looks like it's trying to encode vp8 into mp4 (which won't work) [13:15:34 CEST] <c_14> wait, nvmd [13:15:44 CEST] <c_14> it thinks the ; is part of the file extension [13:16:17 CEST] <c_14> I don't think you need the "; done" in batch anyway? [13:17:39 CEST] <urdne> i've tried another copy/paste solution https://stackoverflow.com/questions/43695545/ffmpeg-batch-convert-for-windo… and it worked, danke c_14 [15:32:09 CEST] <kebabas> Hello how to encode video and leave as HDR format im using this command ffmpeg -i input.mkv -c:v dnxhd -vf "scale=4096:2160,fps=30000/1001,format=yuv444p10le" -profile:v dnxhr_444 outputas.mov [15:35:51 CEST] <kebabas> please help me someone :) [16:10:22 CEST] <kebabas> hello anyone heres? [16:21:43 CEST] <RonaldsMazitis> hello [16:21:52 CEST] <RonaldsMazitis> I am trying to use ffmpeg on windows 7 [16:22:40 CEST] <RonaldsMazitis> ffmpeg -framerate 24 -i img%03d.png output.mp4 I have images named img000.png img022.png etc [16:22:53 CEST] <RonaldsMazitis> but cmd is saying there is no file named [16:22:55 CEST] <RonaldsMazitis> like that [16:30:17 CEST] <RonaldsMazitis> I am trying to make "slideshow" [16:30:22 CEST] <RonaldsMazitis> 1 images per second [16:33:52 CEST] <kebabas> seems here is hard to get support from experienced users :( [16:34:06 CEST] <RonaldsMazitis> Could find no file with path 'img%03d.png' and index in the range 0-4 img%03d.png: No such file or directory [16:34:13 CEST] <RonaldsMazitis> img000.png.png img011.png.png [16:38:00 CEST] <DHE> .png.png ? [16:39:15 CEST] <RonaldsMazitis> ok that was mistake [16:39:24 CEST] <RonaldsMazitis> so how do I get [16:39:30 CEST] <RonaldsMazitis> one image per second [16:41:18 CEST] <RonaldsMazitis> ok [16:41:23 CEST] <RonaldsMazitis> I understood [16:42:23 CEST] <DHE> also it's expected there will be 000, 001, 002, 003, 004, 005, etc. if it skips straight from 000 to 011 that could be a problem [16:43:11 CEST] <DHE> ffmpeg -framerate 1 -i "img%03d.png.png" [...] [16:44:08 CEST] <kebabas> @DHE do you understand about encoding to dnxhr format? [16:44:34 CEST] <DHE> no [16:49:26 CEST] <RonaldsMazitis> my mp4 is not readablet [16:49:28 CEST] <RonaldsMazitis> by phone [16:49:38 CEST] <RonaldsMazitis> and program does not take avi [16:52:09 CEST] <DHE> RonaldsMazitis: ffmpeg [...] -movflags faststart -pix_fmt yuv420p output.mp4 [16:55:45 CEST] <RonaldsMazitis> height not divisible by 2 (272x83) [16:59:44 CEST] <DHE> sigh... [17:41:55 CEST] <RonaldsMazitis> ffmpeg -framerate 1 -i img%03d.png output.mp4 [17:42:39 CEST] <RonaldsMazitis> fails [17:42:51 CEST] <RonaldsMazitis> file does not plays [17:45:09 CEST] <pzich> RonaldsMazitis: what are you playing it with? you probably want to change the pix_fmt [17:45:38 CEST] <th3_v0ice> Some time ago you guys told me that muxer is able to handle one timestamp wraparound and that it will basically not wrap timestamps around next time wraparound happens. Is this fixed in the latest release of library? [17:49:42 CEST] <ddubya> th3_v0ice, no idea about that, but what is causing the wraparound? Maybe it can be avoided [17:50:10 CEST] <RonaldsMazitis> pzich [17:50:12 CEST] <RonaldsMazitis> how [17:50:13 CEST] <RonaldsMazitis> ? [17:50:31 CEST] <RonaldsMazitis> it kinda worked but I choosed wrong color background [17:50:35 CEST] <RonaldsMazitis> now it is stuck [17:52:27 CEST] <pzich> stuck? [17:52:38 CEST] <pzich> something like -pix_fmt yuvj420p [17:52:47 CEST] <pzich> or yuv420p depending on how old your ffmpeg is [17:53:38 CEST] <RonaldsMazitis> did not work [17:54:17 CEST] <pzich> what are you playing it with? [17:54:28 CEST] <RonaldsMazitis> ffmpeg [17:54:52 CEST] <RonaldsMazitis> images are 271x85 [17:54:53 CEST] <RonaldsMazitis> big [17:55:20 CEST] <RonaldsMazitis> I need one image per second [17:55:44 CEST] <th3_v0ice> ddubya, timestamps wraparound in udp. [17:55:45 CEST] <pzich> I think you're going to want your resolution to be a multiple of 2. ffmpeg is probably already adjusting for that though [17:56:20 CEST] <th3_v0ice> Do you know where is the code that is handling the wraparound in mpegts muxer? [17:56:20 CEST] <pzich> does your file play back in vlc or any other app? [17:57:13 CEST] <RonaldsMazitis> ffmpeg -framerate 0.2 -i img%03d.png -vf fps=10 -pix_fmt yuv420p output.mp4 [17:57:19 CEST] <RonaldsMazitis> [libx264 @ 0x1cfa340] height not divisible by 2 (272x83) [17:57:27 CEST] <pzich> correct [17:57:39 CEST] <pzich> your height is 85 and 85 is not divisible by 2 [17:58:00 CEST] <pzich> well actually ffmpeg is saying 272x83, are they that or 271x85? [18:00:55 CEST] <RonaldsMazitis> okay [18:00:57 CEST] <RonaldsMazitis> I changed [18:01:03 CEST] <RonaldsMazitis> still my video does not palys [18:01:04 CEST] <RonaldsMazitis> plays [18:01:57 CEST] <RonaldsMazitis> ffmpeg -framerate 1 -i img%03d.png now worked [18:02:06 CEST] <RonaldsMazitis> but my video is only one frame [18:02:34 CEST] <pzich> and your images are a continuous sequence of numbers like img001.png? [18:02:39 CEST] <RonaldsMazitis> yeah [18:02:54 CEST] <RonaldsMazitis> from img001 to img051 [18:03:06 CEST] <ddubya> th3_v0ice, nope. I do know that the concat function of ffmpeg can deal with it, so it is possible. Maybe using a bitstream filter or modifying packets directly via the api [18:04:44 CEST] <th3_v0ice> I am using the API :) [18:04:44 CEST] <pzich> RonaldsMazitis: hmm, this says it expects to start at 0, although if it's making a video of anything it seems like it's finding them https://en.wikibooks.org/wiki/FFMPEG_An_Intermediate_Guide/image_sequence#F… [18:04:53 CEST] <pzich> maybe try -start_number 1? [18:05:35 CEST] <pzich> might also be worth trying the glob pattern [18:08:23 CEST] <ddubya> th3_v0ice, ok so what you need to do is look for the packet dts/pts to wrap, and modify the values to make it continous [18:08:31 CEST] <ddubya> avpacket that is [18:08:51 CEST] <ddubya> before passing packet to the muxer [18:09:01 CEST] <RonaldsMazitis> ffmpeg -framerate 1 -pattern_type glob -i img%03d.png output.mp4 [18:09:07 CEST] <RonaldsMazitis> Could not find codec parameters for stream 0 (Video: png, none(pc)): unspecified size [18:09:07 CEST] <RonaldsMazitis> Consider increasing the value for the 'analyzeduration' and 'probesize' options [18:09:24 CEST] <RonaldsMazitis> help [18:09:24 CEST] <RonaldsMazitis> me [18:10:27 CEST] <RonaldsMazitis> ffmpeg -framerate 10 -pattern_type glob -i '*.jpg' -c:v libx264 -pix_fmt yuv420p out.mp4 [18:10:30 CEST] <RonaldsMazitis> this one works [18:12:36 CEST] <th3_v0ice> ddubya, While I appreciate your help, this information is not helping :) [18:13:28 CEST] <ddubya> do you require more details? [18:14:25 CEST] <th3_v0ice> I have already done this, these DTS information wraps around at 34bits and mpegts timestamp is 33. My question is what is the FFmpeg doing to fix the wraparound from 34 to 33 bits first time. [18:14:48 CEST] <ddubya> oic [18:14:58 CEST] <ddubya> so it isn't at the packet level [18:15:19 CEST] <th3_v0ice> Its on a muxer level. [18:15:41 CEST] <ddubya> well mpeg streams have their own internal timestamps right [18:16:22 CEST] <ddubya> the system layer has a different one [18:18:02 CEST] <th3_v0ice> Packets have timestamps which are represented in stream timebase. Not sure about "system layer" [18:19:07 CEST] <ddubya> Its my understanding that the elementary streams "ES" are packetized within the transport/system layer (TS) and there are different timestamps in each, though ideally they should be related [18:19:23 CEST] <ddubya> The TS being the outside layer represented in AvPacket [18:22:08 CEST] <th3_v0ice> Timestamps of those packets are just timestamps of AVPacket. [18:22:17 CEST] <th3_v0ice> PES packet in case of MpegTS [18:49:11 CEST] <ddubya> th3_v0ice, I didn't think that AVPacket timestamps could wrap around without causing a failure. Muxers want increasing values. You are saying it continues to work after wrapping around the first time? but no the second? [18:50:38 CEST] <th3_v0ice> First wraparound is handled, timestamp continue from 90k to 150k. Then wraparound happens again, this time they are not continuing it basically breaks. [18:57:05 CEST] <ddubya> can you segment the output to keep it from wrapping? Isn't the first wrap something like 26 hours? [19:56:51 CEST] <Aelius> If I have a 239.76 fps video I want to convert to slow motion. I used the following command: -filter:v "setpts=24.0*PTS" -r 29.97 [19:57:02 CEST] <Aelius> where 239.76/8 = 29.97 [19:57:20 CEST] <Aelius> The output looks ok but I want to know if that was the best way to go about this [19:59:07 CEST] <DHE> you might also try: ffmpeg -r 1 -i input.mp4 -c:v copy -an output.mp4 (intentionally strips out the audio track) [19:59:28 CEST] <DHE> I think that's right [20:01:45 CEST] <Aelius> -r 1 preserves the speed of the video and makes it 1fps [20:02:04 CEST] <Aelius> ie it gives me a timelapse of 1 picture every second [20:03:37 CEST] <Aelius> My goal is to slow down the video without losing any frames [20:04:27 CEST] <Aelius> -r 1 skips 239 frames off every second :P [20:05:46 CEST] <DHE> where you put the -r parameter matters [20:05:53 CEST] <DHE> before -i it's treated as a framerate override on the input [20:06:02 CEST] <DHE> after -i it's treated as an output framerate request [20:06:13 CEST] <Aelius> ok [20:08:44 CEST] <Aelius> yeah that works! thanks. But how portable is a 2fps video? Will browsers, social media sites, video players all handle it correctly? [20:09:16 CEST] <furq> you probably want to set -r again after -i to set a more compatible output framerate [20:09:33 CEST] <furq> as an output option it'll just duplicate frames to get the requested rate [20:09:39 CEST] <Aelius> ok nice [20:12:24 CEST] <DHE> yeah but I'm aiming for a fast no-transcode conversion. it should be as playable as the original, but keyframes will be quite rare affecting seeking [20:14:43 CEST] <Aelius> would -r 2 strangely interfere with the fractional 239.76 source fps? [20:17:13 CEST] <furq> not really [20:17:36 CEST] <furq> it'd mean that the playback speed wouldn't be a clean fraction of the source, if that matters [20:20:34 CEST] <kebabas> Hello anyone can help me with encoding to dnxhr and not losing hdr metadata info from file? [20:20:59 CEST] <kebabas> im using this command ffmpeg -i input.mkv -c:v dnxhd -vf "scale=4096:2160,fps=30000/1001,format=yuv444p10le" -profile:v dnxhr_444 outputas.mov [20:21:14 CEST] <kebabas> but on output im not getting bt2020 color [20:24:32 CEST] <kepstin> my impression is that most of that info is stored as container-level metadata? It might be that ffmpeg doesn't know how to write that into mov [20:27:10 CEST] <furq> you need to specify -colorspace/-color_trc/-color_primaries if you're reencoding [20:27:26 CEST] <kebabas> how to do it ;D? [20:27:32 CEST] <kebabas> im nab at this things [20:29:59 CEST] <kepstin> kebabas: you take the list of options that furq mentioned, realize that they're command-line options for the ffmpeg tool, and then look them up in the docs https://www.ffmpeg.org/ffmpeg-codecs.html#Codec-Options to find out what values are accepted. [20:30:45 CEST] <kebabas> problem is i tried different commands and even made reddit thread but still cant get ir correcct [20:31:00 CEST] <kebabas> tried using scale=in_color_matrix=bt2020:out_color_matrix=bt2020 [20:31:05 CEST] <kebabas> but still cant get it right [20:33:16 CEST] <kebabas> 1 guy said its possible to merge it later but tried with mkvmerge and still cant get ir right [20:33:23 CEST] <kepstin> that said, it's unclear whether the dnxhd encoder actually does anything with those options? [20:34:16 CEST] <kepstin> ah, the mov muxer should be using those [20:34:22 CEST] <kepstin> to set metadata [20:34:31 CEST] <kebabas> my original file is in hevc codec with hdr metadata, when i reencoding it to dnxhr im losing hdr metadata and dont know how to keep it [20:35:47 CEST] <kebabas> here is file info [20:35:48 CEST] <kebabas> https://pastebin.com/YkX7iSaX [20:36:04 CEST] <kepstin> kebabas: may I suggest that you scroll your irc client up and re-read furq and my responses, where we tell you what to do? [20:36:21 CEST] <kebabas> sorry i was loged off and im using web client [20:36:27 CEST] <kebabas> i dont have history :(( [20:38:00 CEST] <furq> -color_primaries bt2020 -colorspace bt2020c -color_trc bt2020_10bit [20:38:17 CEST] <furq> or -colorspace bt2020nc if that's what you want [20:38:32 CEST] <furq> i assume that swscale is smart enough to keep the source primaries without being asked to [20:38:37 CEST] <furq> but i don't actually know for sure [20:39:29 CEST] <kebabas> ffmpeg -i input.mkv -color_primaries bt2020 -colorspace bt2020c -color_trc bt2020_10bit -c:v dnxhd -vf "scale=4096:2160,fps=30000/1001,format=yuv444p10le" -profile:v dnxhr_444 outputas.mov [20:39:31 CEST] <kebabas> like this? [20:39:58 CEST] <furq> probably [20:40:16 CEST] <furq> i've only ever used it with h264/hevc though [20:42:19 CEST] <kebabas> ok trying to encode for 100 time :D [20:42:23 CEST] <kebabas> i hope its going work [20:48:57 CEST] <kebabas> i did it and still not working :/ [20:49:01 CEST] <kebabas> shiiiiiet [20:51:44 CEST] <kepstin> try a different codec maybe? [20:52:13 CEST] <kebabas> furq: anyway thanks for help [20:52:24 CEST] <kebabas> i want to use apple pro ress or dnxhr [20:53:12 CEST] <kebabas> im trying now same commands with apple pro ress maybe its going work [20:53:12 CEST] <kepstin> the prores encoders do at least look at the various color fields, unlike the dnxhd encoder. so it could be worth a try. [21:10:51 CEST] <kebabas> funny thing, every new tip i find on google its always different command lines :D [21:22:59 CEST] <kebabas> how to understand in media info [21:23:00 CEST] <kebabas> Color primaries : BT.2020 colour_primaries_Original : BT.709 Transfer characteristics : PQ transfer_characteristics_Original : BT.709 Matrix coefficients : BT.2020 non-constant matrix_coefficients_Original : BT.709 [21:23:25 CEST] <kebabas> atleast im getting something with proress [21:46:31 CEST] <pa[m]> funny, i was about to ask in here about color spaces. when you give ffmpeg an RGB source and a movie output (`prores_ks`) for example, does it assume going from sRGB to Rec 709? [21:47:13 CEST] <pa[m]> I would like to render a Prores 4444 movie in RGB without any color conversions, and not in YUV. As i understand Prores 4444 supports RGB and YUV [21:51:24 CEST] <kepstin> pa[m]: in most cases when you use the automatic rgb to yuv conversion I think you'll get results equivalent to rec 709 [21:51:30 CEST] <pa[m]> But i'm also curious what the "correct" way is to go from sRGB ~2.2 gamma to Rec 709 2.4 [21:51:46 CEST] <kepstin> in particular, i believe it does *not* do primary conversion, by sRGB and rec 709 use the same primaries [21:52:01 CEST] <pa[m]> but does it do a gamma conversion? [21:52:12 CEST] <kepstin> i'm honestly not sure :/ [21:53:02 CEST] <pa[m]> time for some tests then... [21:53:18 CEST] <kepstin> if you want to be sure about that, it might be best to explicitly do a conversion, possibly using the colorspace or zscale filters. [21:55:17 CEST] Action: pa[m] sent a long message: < https://matrix.studiopa.org/_matrix/media/v1/download/matrix.studiopa.org/w… > [21:55:30 CEST] <pa[m]> seems like `prores_ks` can't write RGB pixels, only YUV [21:56:01 CEST] <kepstin> that's not unexpected [21:56:18 CEST] <kepstin> patches welcome, i suppose :) [21:56:26 CEST] Action: kepstin doesn't know much about prores [21:57:34 CEST] <pa[m]> cool, just wanted to make sure i wasn't misunderstanding. I am still thankful for free software! [21:59:52 CEST] <pa[m]> but i suppose you could still just store sRGB in YUV, assuming the YUV->RGB conversion is lossless (pretty sure it is). Just want to make sure it doesn't do any colorspace conversions; but yes, if it does i can surely force it not to with the colorspace filters... [22:01:46 CEST] <kepstin> the conversion isn't completely lossless, you have to account for the levels (full range vs. tv range) and rounding/precision issues. [22:02:29 CEST] <pa[m]> is it possible to pipe custom color primaries or transfer functions into the colorspace filter, or can you only use the presets [22:02:59 CEST] <kepstin> but yeah, with 4:4:4 encoding you could certainly just throw rgb into the yuv channels and have the encoder encode it as if it was yuv. [22:03:09 CEST] <pa[m]> specifically curious about P3 colorspace [22:09:14 CEST] <kepstin> colorspace filter already supports the primaries for P3, listed as smpte431 (DCI) and smpte432 (D65) [22:11:30 CEST] <kepstin> i dunno what you're supposed to use for color transfer. apparently apple uses srgb for "display p3" and the studio stuff uses gamma 2.6 which that filter doesn't seem to support. [22:11:40 CEST] <kebabas> kepstin: do you encoded with apple pro ress? i have few questions [22:12:16 CEST] <pa[m]> yeah i think "display p3" is 2.2 gamma? [22:12:35 CEST] <pa[m]> and AFAIK P3 D65 is usually used with 2.2 gamma since it's for computer monitors [22:12:37 CEST] <pa[m]> but i may be mistaken [22:12:56 CEST] <kepstin> well, sRGB isn't quite the same thing as 2.2 gamma [22:18:45 CEST] <pa[m]> so for sRGB->Rec 709 [22:18:49 CEST] <pa[m]> `-vf "colorspace=iprimaries=bt709:itrc=srgb:ispace=bt709:primaries=bt709:trc=bt709:space=bt709"` [22:18:51 CEST] <pa[m]> does that looks sensible [22:20:02 CEST] <pa[m]> i am not quite clear on what "color space" means here (in compositing software i am used to only dealing with primaries and transfer) [22:20:07 CEST] <kepstin> pa[m]: yeah, that should basically *just* do the gamma conversion from sRGB to rec 709 [22:20:21 CEST] <kepstin> so, "space" is actually a sort of "preset all" option [22:20:39 CEST] <pa[m]> i tried this without "space" and it yelled at me [22:29:03 CEST] <kepstin> hmm. so as far as I can tell, "space" here refers to the coefficients used when doing rgb to yuv conversion [22:30:45 CEST] <pa[m]> guess i need to do some research then, cause i have no idea what that means [22:33:08 CEST] <kepstin> in this case i'm pretty sure bt709 is correct - unless, as we found out with a different person who came in here yesterday, the video was a screencap made with shadowplay - in which case you'd use bt601 as ispace ;) [22:39:26 CEST] <pa[m]> so if i did something like this `colorspace=iprimaries=bt709:itrc=srgb:ispace=bt709:primaries=bt709:trc=srgb:space=bt709` [22:39:35 CEST] <pa[m]> would that force ffmpeg to not do any color conversions [22:39:49 CEST] <pa[m]> that might be implicit when you give it rgb and expect a video [22:39:53 CEST] <SoMuchForSubtlet> Hi, I have a input with multiple audio and video tracks. I want to stream the bese video track and the english audio track to a RTMP server, whats the best way to do this? [22:40:05 CEST] <SoMuchForSubtlet> *best video [22:40:13 CEST] <kepstin> pa[m]: that would do nothing, but it would mark the output video with the desired color space properties i guess. [22:40:29 CEST] <kepstin> SoMuchForSubtlet: how do you know which one is the "best"? [22:40:54 CEST] <SoMuchForSubtlet> the one it picks by default, highest bitrate and resolution [22:41:35 CEST] <kepstin> SoMuchForSubtlet: what does ffmpeg print when you run "ffmpeg -i <your input>" ? (please pastebin the results) [22:42:20 CEST] <SoMuchForSubtlet> here is the ffprobe https://pastebin.com/CgqwCny3 [22:50:30 CEST] <kepstin> alright, so you could probably get away with `-map a:m:language:eng` to select an english audio track (they all seem the same). I really don't know a generic way to select the best video stream in this case. If they're consistent in the number of programs and program ids they use, you could use `-map p:6:v` to statically select the one from program 6 :/ [22:51:46 CEST] <pa[m]> anyone know what the `colorspace` equivalent of `-vf scale=out_color_matrix=bt709` would be? because `-vf "colorspace=iprimaries=bt709:itrc=srgb:ispace=bt709:primaries=bt709:trc=bt709:space=bt709"` gives a different result [22:52:16 CEST] <kepstin> pa[m]: it probably depends on the input video [22:52:40 CEST] <pa[m]> input is an RGB PNG sequence [22:52:46 CEST] <SoMuchForSubtlet> kepstin yea I used that to get the audio track, I was also stuck on how to get the right video. Sadly the number of video tracks vary [22:53:26 CEST] <pa[m]> so perhaps it does not interpret the PNG sequence to be sRGB, maybe it is using 2.2 gamma or something and not the special sRGB transfer function [22:53:30 CEST] <kepstin> SoMuchForSubtlet: you might have to just check the input (e.g. with ffprobe) and then build a matching ffmpeg command line then :/ [22:53:37 CEST] <SoMuchForSubtlet> the only solution I can think of is to write a script to parse the source m3u8 file and get the video track number that way [22:56:37 CEST] <kepstin> i'd use ffprobe to avoid the m3u8 parsing, it can dump in a few different formats including json which is kinda nice. [22:57:22 CEST] <SoMuchForSubtlet> kepstin: maybe I could select one audio track and all video tracks with one ffmpeg command and pipe that into a second ffmpeg command that will select the right video track? [22:57:59 CEST] <kepstin> SoMuchForSubtlet: still wouldn't help, how would the second ffmpeg command be able to know which video track to select? [22:58:43 CEST] <SoMuchForSubtlet> it selects the best by default when no map is given [23:00:04 CEST] <kepstin> hmm? no, it selects the first, not the best. [23:00:25 CEST] <kepstin> unless there's some weird interaction with "Programs" that i'm not familiar with [23:02:20 CEST] <SoMuchForSubtlet> no, when I streamed without a map set it picked the 1080p video feed and the first audio track. the 1080p feed is not the first according toffprobe [23:03:43 CEST] <kepstin> SoMuchForSubtlet: huh. what does it do if you use just "-map 0:v:0" ? [23:04:23 CEST] <SoMuchForSubtlet> let me try [23:07:19 CEST] <SoMuchForSubtlet> https://pastebin.com/raw/D2xQKVQ8 [23:07:28 CEST] <SoMuchForSubtlet> and it's only streaming audio it seems [23:07:53 CEST] <SoMuchForSubtlet> https://player.angelthump.com/?channel=somuchforsubtlety this is the live feed [23:08:16 CEST] <SoMuchForSubtlet> didnt even pick the right audio haha [23:09:16 CEST] <qacky> paste shows both audio and video [23:10:11 CEST] <SoMuchForSubtlet> yea but it looks like only auio is arriving [23:12:19 CEST] <SoMuchForSubtlet> it picked the first audio feed, not the english one [23:12:24 CEST] <SoMuchForSubtlet> and the worst video feed [23:13:31 CEST] <pa[m]> sigh.... i can't reproduce the sRGB->Rec709 that is done natively in After Effects (using ICC profiles/color management) or using Blackmagic Fusion (using the Gamut node) in FFMPEG [23:13:36 CEST] <SoMuchForSubtlet> this is the output without any maps https://pastebin.com/d6dVCnJB [23:13:40 CEST] <pa[m]> perhaps it is because ffmpeg wants to be in YUV land [23:14:45 CEST] <SoMuchForSubtlet> ah, I didnt get video because I didnt set a video codec [23:14:51 CEST] <SoMuchForSubtlet> still not the right tracks tho [23:17:17 CEST] <kepstin> SoMuchForSubtlet: yeah, you might just have to script it then :/ [23:17:40 CEST] <kepstin> SoMuchForSubtlet: ffprobe the input, use your own logic to pick the tracks, then run ffmpeg with specific options [23:18:19 CEST] <SoMuchForSubtlet> yea I'll do that, thanks for the help :) [00:00:00 CEST] --- Tue Jun 18 2019

1 0