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

Sat Sep 23 03:05:02 EEST 2017

[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