[02:53:25 CET] <kierank> j-b: as in the gaming Oliver Collyer? [09:36:54 CET] <j-b> kierank: maybe, dunno [12:35:43 CET] <_bluez> exit [12:36:39 CET] <_bluez> Hello! I want to work on hief support for gsoc... can anyone suggest me a qualification task that is not already taken? [12:37:25 CET] <_bluez> heif* [12:41:38 CET] <durandal_1707> _bluez: contact mentor by mail [12:44:35 CET] <cone-101> ffmpeg 03Mark Reid 07master:283ce69a107b: avformat/mxfenc: allow user comments for opatom muxer [12:44:36 CET] <cone-101> ffmpeg 03Mark Reid 07master:7ff89574c78d: fate/mxf: add mxf user comments tests [12:46:15 CET] <_bluez> durandal_1707: Thanx.. will do that :) [12:50:34 CET] <jkqxz> What should be done with the patch adding parallelism to the ffmpeg utility? [12:50:44 CET] <jkqxz> The most recent version has added big locks around some specific cases I noted in the previous review, but there are still a load of data races in there. [12:51:47 CET] <jkqxz> I don't really have much confidence that the submitter understands what they're doing, since it seems like their response to the concerns has been reactive to specific cases only. [12:52:10 CET] <JEEB> :/ [12:52:14 CET] <JEEB> that's unfortunate [12:52:15 CET] <durandal_1707> tell him to rewrite ffmpeg from scratch [12:52:18 CET] <jkqxz> And I don't want to spend days doing their audit work on what is a very hard problem. [12:52:30 CET] <JEEB> but yea, that's what was my initial response to it [12:53:41 CET] <jkqxz> I feel like if I point out another race, we'll just get another version with another lock and be no further forward in believing that the result is actually correct. [12:57:08 CET] <jkqxz> durandal_1707: Tbh that's the right answer to properly adding parallelism. Adding it as a bolt-on in code which wasn't written with it in mind at all is very difficult. [12:57:23 CET] <JEEB> yea [16:45:11 CET] <faLUCE> Hello. While decoding mjpeg frames I have this continuous msg: "[mjpeg @ 0x7efda4003b80] unable to decode APP fields: Invalid data found when processing input" . This is the command that I executed: "ffplay -f v4l2 -input_format mjpeg -video_size 640x480 -framerate 25 -i /dev/video0". I'm seeing that a patch has been submitted for that: https://git.ring.cx/savoirfairelinux/ring-daemon/commit/ [16:45:13 CET] <faLUCE> 4036b7708fa7de996b0585a7bc432397c77d41b2 but I don't understand if the log message is still a valid message. In addition, I don't see the patch in the git current image of ffmpeg... [16:46:24 CET] <faLUCE> in 2.8.7 version I did not have that msg... [16:50:23 CET] <faLUCE> so, I don't understand if I have to ignore this msg... [16:53:53 CET] <jkqxz> What is actually in the APP block in your JPEG? [16:54:03 CET] <faLUCE> jkqxz: AVI1 [16:54:11 CET] <faLUCE> In a chat of some time ago, another user had the same issue: http://lists.ffmpeg.org/pipermail/ffmpeg-devel-irc/2017-September/004509.htm... . He solved the issue by downgrading ffmpeg to 3.3.3. [16:56:05 CET] <jkqxz> Is that over the end of the file? That won't hit the < 6 case (since it's 2 byte length + 4 bytes data), and those are the only two ways to get INVALIDDATA there. [16:57:07 CET] <jkqxz> Or maybe the length in the file is wrong. [16:57:32 CET] <faLUCE> jkqxz: no, they are bytes 6-7-8-9 of the frame [16:57:56 CET] <faLUCE> jkqxz: which length ? [16:59:20 CET] <jkqxz> An APP block is two bytes of length followed by the data. The length field should match the total length (that is, the length of the data plus two). [17:01:34 CET] <faLUCE> jkqxz: the total lenght of what? of the frame or of the APP block? [17:01:52 CET] <jkqxz> Of the APP block. [17:02:02 CET] <faLUCE> let me check [17:05:11 CET] <jkqxz> <https://www.w3.org/Graphics/JPEG/itu-t81.pdf>, page 48. [17:10:14 CET] <faLUCE> jkqxz: bytes 4-5 have values of 0 and 33. Then the lenght you say is 33. But I don't understand if this length should be =4 or the APP field is longer than "AVI1". I can't find mjpeg specs on google [17:15:11 CET] <faLUCE> I tried to set it manually to 4 and to 6. But still get the warning [17:17:11 CET] <jkqxz> Show the first line of a hexdump of the file? ("hd file | head -1") [17:18:32 CET] <faLUCE> jkqxz: how many bytes? I'm running a program made with libavcodec [17:19:18 CET] <jkqxz> At least 11. [17:22:47 CET] <faLUCE> jkqxz: ff d8 ff e0 0 21 41 56 49 31 0 1 1 1 0 78 0 78 0 0 0 0 0 0 0 0 0 0 0 0 [17:25:04 CET] <faLUCE> jkqxz: (40 bytes) ff d8 ff e0 0 21 db 041 56 49 31 0 1 1 1 0 78 0 78 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ff [17:25:32 CET] <jkqxz> Huh. I don't see how that can generate the error at all. [17:25:40 CET] <jkqxz> Do you perhaps have another APP section later in the file? [17:28:50 CET] <faLUCE> let me check [17:29:40 CET] <faLUCE> (not easy, I have to debug libavcodec) [17:34:56 CET] <faLUCE> jkqxz: here's one of the frames captured with ffmpeg -f v4l2 -input_format mjpeg -video_size 640x480 -framerate 25 -i /dev/video0 thumb%04d.jpg ----> https://unsee.cc/98e1a0b8/ [17:35:13 CET] <faLUCE> (with the output showing all the warning msg) [17:35:41 CET] <faLUCE> I have the same issue with all the usb cameras I used [17:41:27 CET] <faLUCE> sorry, I had connection problems [17:46:26 CET] <faLUCE> I suspect it's a bug [17:47:23 CET] <jkqxz> I don't see anything useful at that link (just an upload page). [17:48:42 CET] <faLUCE> jkqxz: sorry: https://unsee.cc/100e3eb2/ [17:49:34 CET] <faLUCE> sorry again jkqxz, let me find another site for uploading [17:50:11 CET] <JEEB> curl -F'file=@/path/to/file' https://0x0.st [17:50:35 CET] <JEEB> for a random sample that should be good enough? [17:52:33 CET] <faLUCE> I can't open http or https port [17:52:45 CET] <faLUCE> https://a.uguu.se/ReegXWAjsTDb_thumb0005.jpg [17:55:22 CET] <faLUCE> well: (thanks to JEEB) [17:55:23 CET] <faLUCE> https://0x0.st/zXN8.jpg [17:55:31 CET] <faLUCE> jkqxz: ^ [17:56:40 CET] <jkqxz> That has no APP blocks or warnings? [17:57:50 CET] <faLUCE> it has the same warning that I said before... [17:58:09 CET] <faLUCE> [mjpeg @ 0x564a00b44740] unable to decode APP fields: Invalid data found when processing input [18:54:41 CET] <thealakazam> Hello, people, I wanted to ask if there are any tutorials or guides for creating muxers wanna try implementing one, for contributing later. [18:55:40 CET] <JEEB> looking at one of the recently added smaller ones might be a good one [18:56:07 CET] <faLUCE> jkqxz: you were right, there's another "ff e0" marker in the header. I don't know why the USB camera put it there, but I don't know either if it's an error of the camera or, instead, the libavcodec jpeg decoder should stop searching other markers when the first one has been found [18:56:12 CET] <JEEB> and generally there's this check-list https://www.ffmpeg.org/developer.html#New-codecs-or-formats-checklist [18:56:47 CET] <faLUCE> jkqxz: IMHO the libavcodec decoder should stop searching other markers when the first one has been found [18:58:00 CET] <llogan> seeing some users complaining that ffmpeg fails to compile using blackmagic SDK 11, but 10.11.4 works fine. i didn't look into it and can't test. [18:58:41 CET] <thealakazam> oh ok thanks, will start reading up on it [18:59:06 CET] <JEEB> :< [18:59:31 CET] <JEEB> I would have linked a simple demuxer and told him that muxers are similar (just different callbacks are registered) [19:00:16 CET] <llogan> scared off by developer.html wall-o-text [19:03:12 CET] <faLUCE> jkqxz: note that the image that I uploaded was a JPEG image (without the MJPEG header) [19:05:42 CET] <JEEB> llogan: I tried to find the "baby's first component" tutorial that I remember seeing on libav's site, but I couldn't find it right away :< [19:05:50 CET] <faLUCE> there should be something broken in ffmpeg > 3.3.3 for MJPEG decoding [19:27:38 CET] <durandal_1707> no way!! [21:35:19 CET] <cone-537> ffmpeg 03Jun Li 07master:c2a221c5ae50: avformat/rtpdec.h remove unused variable [21:42:52 CET] <Lynne> does someone here know aarch64 assembly? [21:43:12 CET] <Lynne> I've written a function but its only 1.25 times faster than C (when #if 1): https://paste.ubuntu.com/p/pbPRXtZZTm/ [00:00:00 CET] --- Thu Mar 14 2019