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

[burek]

[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.html   . 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