[Ffmpeg-devel-irc] ffmpeg-devel.log.20190621

[burek]

[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