[01:45:16 CEST] <cone-234> ffmpeg 03Carl Eugen Hoyos 07master:724cf83f1000: Remove some unneeded casts of bit_rate. [02:25:33 CEST] <cone-234> ffmpeg 03Lou Logan 07master:183fd30e0f6f: Fix several typos [03:56:51 CEST] <newbie1> hello, I have an H264 stream (a collection of raw NAL units) that I pump into FFmpeg to decode video. The problem is that FFmpeg avcodec_receive_frame() is returning ONLY 1rd of the decoded resolution. [03:57:35 CEST] <newbie1> on the other hand, if I pump the NALs into av_parser_parse2() then the decoded frame returned by avcodec_receive_frame() is 100% of the frame. [03:58:55 CEST] <newbie1> It seems like a bug in either FFmpeg or some flag isn't set, but I get no decoding errors so I can't tell why decoding doesn't work with this sequence "avcodec_send_packet, avcodec_receive_frame" but works with this sequence "av_parser_parse2,avcodec_send_packet, avcodec_receive_frame" [04:00:54 CEST] <newbie1> This sort of problem only seems to happen when H264 stream has a group of few consecutive IDR frames in a row (instead of the usual single IDR every few second) [04:20:20 CEST] <newbie1> Is it required to call av_parser_parse2()? It seems like with the stream I have I cannot just use avcodec_send_packet()/avcodec_receive_frame() as I get partially decoded images (again no errors in logs). [04:23:25 CEST] <wm4> newbie1: yes, ffmpeg expects 1 frame per packet [04:23:36 CEST] <wm4> and the parser can take care of that [04:24:10 CEST] <newbie1> I have tried splitting the NALs and feeding 00 00 00 01 NAL into the avcodec_send_packet() one at a time, still doesn't work [04:24:38 CEST] <newbie1> like I said with most H264 streams I've seen it works fine, it's this stream that contains group of IDRs that decoding seems to silently fail. [04:24:58 CEST] <newbie1> Is there any flags or options I can explore? [04:25:52 CEST] <wm4> does ffmpeg's raw h264 demuxer with ffmpeg cli eat the stream? [04:26:43 CEST] <newbie1> not sure if I understand that fully. If I pipe the data into FFmepg.exe it works (I suspect because behind the scene it uses parser2) [04:27:23 CEST] <newbie1> so I know that the data is good and it's all there...the problem seems to be the way it's fed into decoder via send packet and receive frame [04:27:37 CEST] <newbie1> I've tested this with FFmepg 3.3.x latest release [04:27:56 CEST] <wm4> so use the parser [04:28:35 CEST] <newbie1> well, the documentation doesn't mention to use parser...also I'm concerned parse is doing extra work such as memcpy etc [04:34:02 CEST] <wm4> yes it will [04:34:25 CEST] <newbie1> ? [04:34:34 CEST] <wm4> it'll do memcpy [04:34:47 CEST] <wm4> even if the docs don't mention it, 1 frame per packet is required [04:35:45 CEST] <newbie1> "1 frame per packet", does that mean the NALs need to be assembled into "1 frame' before calling avcodec_send_packet()?? [04:36:16 CEST] <rcombs> yes, and the parser will do that [04:36:27 CEST] <rcombs> memcpy on coded data is cheap; don't worry about it [04:36:56 CEST] <wm4> typically you only need to "cut" the stream on boundaries between the required slice NALs [04:37:13 CEST] <newbie1> understood. Should I file a bug since avcodec_receive_frame() returns okay but the decoded frame is partial. [04:37:18 CEST] <wm4> since you need padded and aligned packets, you probably need to do memcpy on some level anyway [04:37:26 CEST] <wm4> no [04:38:41 CEST] <newbie1> is there existing function that can "cut" the stream on boundaries? My input is a start_code data start_code data .... [04:41:08 CEST] <wm4> well, the parser [04:41:16 CEST] <newbie1> :) I figured you'd say that [04:43:08 CEST] <newbie1> should we update documentation to say use parser https://www.ffmpeg.org/doxygen/3.2/group__lavc__encdec.html [04:43:36 CEST] <newbie1> There is no mentioning of parser in "send/receive encoding and decoding API overview" [04:44:23 CEST] <newbie1> I think this change has come to be when the send/recv functions were introduced as part of the new API [04:49:25 CEST] <rcombs> did the docs for the old API mention that? (the old API also required correctly-split packets IIRC) [04:49:29 CEST] <rcombs> either way, yeah, it'd be good to mention [04:52:59 CEST] <wm4> we can't really document the exact requirements for each codecs in the doxygen [04:53:12 CEST] <wm4> that would blow up quickly [04:53:31 CEST] <wm4> maybe per-codec external docs (like with for private options), but nobody reads those [05:00:04 CEST] <wm4> jkqxz: can you ACK or NACK the v4l patch? [05:00:14 CEST] <rcombs> wm4: why not just say you need to use the parser if one's available [05:01:55 CEST] <wm4> that would be a bit too strong [08:42:37 CEST] <liyou> hi [08:43:04 CEST] <liyou> does ffmpeg run slowly? [08:50:06 CEST] <wm4> no, it's super fast [08:54:41 CEST] <liyou> why do you say that [08:56:27 CEST] <wm4> because it's the Truth(tm)(C) [09:45:25 CEST] <nevcairiel> your very generic question can only get very generic answers. In some areas its the fastest solution available anywhere, some other areas could probably use enhancements [10:42:40 CEST] <BtbN> Why do people randomly E-Mail me to push their patch? It's not in any code I maintain, nor in an area I have any experience with. [10:45:34 CEST] <wm4> it only takes 1 or 2 people who know you to lose faith in humanity [10:45:47 CEST] <wm4> (worst case) [10:48:03 CEST] <rcombs> huh, I don't get those [10:48:11 CEST] <rcombs> don't tell them I have push access, I guess [10:48:13 CEST] <nevcairiel> me neither [10:48:33 CEST] <BtbN> I get at least one or two mails a month asking me about random patches [10:48:47 CEST] <BtbN> I usually ignore them, unless it's nvenc/cuda related [10:48:48 CEST] <rcombs> wm4: also wait nononono it's not "super fast" [10:48:49 CEST] <rcombs> it's a [10:48:50 CEST] <rcombs> Hyper fast Audio and Video encoder [10:48:54 CEST] <atomnuker> rcombs: flac imagecover patch v4 or whatever pll0x [10:48:57 CEST] <wm4> right, hyper fast [10:49:06 CEST] <rcombs> atomnuker: I need sleep [10:49:16 CEST] <rcombs> remind me in like 32400 seconds [10:49:25 CEST] <wm4> (there was even a patch to remove "hyper fast" because someone contended the speed) [10:49:42 CEST] <rcombs> lol [10:50:04 CEST] <rcombs> how do you get git to generate patch version numbers anyway [10:50:10 CEST] <rcombs> in send-email [10:50:47 CEST] <wm4> -v3 [10:53:41 CEST] <atomnuker> rcombs: --subject-prefix="PATCH v3" in format-patch [10:54:17 CEST] <nevcairiel> using -v seems easier [10:54:28 CEST] <rcombs> TIL about -v [10:54:36 CEST] <rcombs> also that arbitrary format-patch args work for send-email [10:54:47 CEST] <nevcairiel> yeah it passes whatever it doesnt handle itself to format-patch [10:54:49 CEST] <nevcairiel> which is kinda handy [10:55:17 CEST] <wm4> sometimes order seems to matter too [10:55:20 CEST] <wm4> rather confusing [10:56:51 CEST] <atomnuker> huh, I didn't know about -vN either [10:57:18 CEST] <wm4> it's well-hidden [10:57:33 CEST] <wm4> <insert git manpage generator joke link> [10:58:28 CEST] <nevcairiel> its just there in the man page [11:24:18 CEST] <thardin> msbuild is such a joke [11:42:11 CEST] <ubitux> the fuck is this export_all shit [11:42:30 CEST] <mateo`> a bit of context: mov.c [11:43:31 CEST] <nevcairiel> some people beleive that allocating all metadata that one might not read is super wasteful, so they need to save a few bytes [11:43:58 CEST] <JEEB> mateo`: btw have you seen crashes inside stagefright? [11:44:24 CEST] <JEEB> like http://up-cat.net/p/82b841eb [11:44:25 CEST] <ubitux> nevcairiel: it's exporting binary as string [11:44:37 CEST] <ubitux> null terminated randomly [11:44:39 CEST] <ubitux> it makes no sense [11:44:45 CEST] <ubitux> CAME : «xs9?>1 ">Î;(Ø©¬ [11:44:48 CEST] <ubitux> SETT : Ç [11:44:52 CEST] <ubitux> MUID : «xs9?>1 ">Î;(Ø©¬?·QI [11:44:55 CEST] <ubitux> GUMI : éß-?Ü|ÙF:Ç©n"Üx [11:44:58 CEST] <ubitux> wth... [11:45:35 CEST] <mateo`> we'd like to export a list (defined by the user) of udta atoms as side data [11:45:38 CEST] <wm4> ubitux: ih what's that [11:45:41 CEST] <wm4> *uh [11:45:46 CEST] <ubitux> -export_all in mov demuxer [11:45:46 CEST] <mateo`> or something that can be exposed to the user [11:45:51 CEST] <mateo`> and remuxed [11:46:14 CEST] <mateo`> not binary in strings [11:46:15 CEST] <wm4> oh referring to the fact that we export random atoms as tags [11:46:25 CEST] <wm4> I hate that [11:46:29 CEST] <ubitux> yes [11:46:32 CEST] <ubitux> all of them are broken [11:46:35 CEST] <ubitux> it's in a string [11:46:36 CEST] <wm4> it just makes random shit end up in remuxed files [11:46:46 CEST] <wm4> where it has nothing lost [11:47:02 CEST] <wm4> s/nothing lost/no business/ [11:47:15 CEST] <mateo`> JEEB: I did not had this crash [11:47:41 CEST] <JEEB> some samsung devices seem to have this sometimes [11:47:43 CEST] <ubitux> we don't have side data for AVFormatContext? [11:48:02 CEST] <mateo`> JEEB: using the ffmpeg wrapper I guess ? [11:48:09 CEST] <nevcairiel> ubitux: no, its either stream or codec [11:48:31 CEST] <ubitux> or packet or frame [11:48:39 CEST] <ubitux> can we add it to formats? [11:48:50 CEST] <nevcairiel> i dont really see the usecase [11:48:57 CEST] <ubitux> exporting these udta [11:49:08 CEST] <mateo`> (using a whitelist provided by the user) [11:49:24 CEST] <nevcairiel> sounds like something extremely specific thats not going to be of use anywhere else, tbh [11:49:41 CEST] <ubitux> pretty sure mov isn't the only format to store random binary user data [11:50:15 CEST] <mateo`> JEEB: do you have a way to reproduce the crash ? [11:50:19 CEST] <JEEB> nope :D [11:50:22 CEST] <wm4> ubitux: obviously export it as hex LOL [11:50:29 CEST] <mateo`> wm4: NO NO NO [11:50:33 CEST] <ubitux> yeah %08x in metadata tags [11:50:35 CEST] <ubitux> let's do this [11:50:43 CEST] <JEEB> I just see the 1-2% of users having that (Ž4@) [11:50:45 CEST] Action: wm4 gets his axe ready [11:50:48 CEST] <ubitux> :) [11:50:48 CEST] <wm4> think carefully! [11:50:58 CEST] <ubitux> i'll go for format side data [11:51:03 CEST] <wm4> what's udta? [11:51:05 CEST] <ubitux> and make export_all do that [11:51:08 CEST] <ubitux> "user data" [11:51:18 CEST] <wm4> so just untyped...? [11:51:23 CEST] <nevcairiel> random undefined unspecified data [11:51:27 CEST] <wm4> pairs of name + binary data? [11:51:32 CEST] <ubitux> all kind of binary atoms [11:51:55 CEST] <ubitux> http://sprunge.us/NCdj [11:52:01 CEST] <wm4> could it be made an AVStream? (though that sounds like something that could be regretted later) [11:52:04 CEST] <nevcairiel> typically it contains text tags [11:52:10 CEST] <nevcairiel> which we read into metadata [11:52:16 CEST] <nevcairiel> but i guess some people shove random shit in there [11:52:22 CEST] <ubitux> wm4: no, it's on the format [11:52:54 CEST] <wm4> if you do it as side data, can we have a proper concept + reuseable implementation, instead of duplicating the buggy crap we have everywhere else? [11:53:18 CEST] <wm4> like, say, have struct AVSideDataList, which could be reused elsewhere [11:54:05 CEST] <mateo`> sounds like a good idea [12:03:24 CEST] <cone-493> ffmpeg 03Yogender Gupta 07master:21e077fcb3d9: avfilter/thumbnail_cuda: add cuda thumbnail filter [12:20:48 CEST] <cone-493> ffmpeg 03Kaustubh Raste 07master:2b1562699749: avcodec/mips: preload data in hevc sao edge 90 degree filter msa functions [12:20:49 CEST] <cone-493> ffmpeg 03Kaustubh Raste 07master:f160a63badfc: avcodec/mips: Remove generic func use in hevc non-uni copy mc msa functions [12:20:50 CEST] <cone-493> ffmpeg 03Michael Niedermayer 07master:2c933c51687d: avcodec/svq3: Fix overflow in svq3_add_idct_c() [12:20:51 CEST] <cone-493> ffmpeg 03Michael Niedermayer 07master:d00fc952b6c2: avcodec/ffv1dec: Fix integer overflow in read_quant_table() [12:20:52 CEST] <cone-493> ffmpeg 03Michael Niedermayer 07master:67da2685e038: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_FIDELITYi*() [14:18:33 CEST] <durandal_1707> BtbN: what patches? [14:19:35 CEST] <BtbN> https://patchwork.ffmpeg.org/patch/2221/ in this case [14:20:11 CEST] <BtbN> Someone should finally fix that certificate [16:37:13 CEST] <sangy> Hello, I noticed that there are two CVE's fixed on ffmpeg but not on ffmpeg2.8. (These are CVE-2017-14223 and -14222). Are there any plans on fixing it ? [17:30:13 CEST] <BtbN> Are you sure 2.8 is even affected? [17:33:03 CEST] <sangy> BtbN: we checked the vulnerable code areas on monday. I think they are there [17:33:22 CEST] <BtbN> Can always just try to apply the patch [17:33:29 CEST] <nevcairiel> those CVEs arent even real vulnerabilities [17:35:59 CEST] <sangy> I imagine, I think one of the patches would be harder to apply because some of the code was refactored to a diff-module [17:36:21 CEST] <sangy> nevcairiel: can you elaborate please? [17:39:14 CEST] <jamrial> oh god, an swscale patch with intrinsics [18:44:21 CEST] <atomnuker> rcombs: reminding you after 9 hours [00:00:00 CEST] --- Sat Sep 23 2017