[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