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

Sun May 29 02:05:04 CEST 2016

[01:49:18 CEST] <cone-681> ffmpeg 03Michael Niedermayer 07master:9106cba22ad8: fate: Add fate-prores-gray
[01:49:19 CEST] <cone-681> ffmpeg 03Michael Niedermayer 07master:f66ca036bca1: avformat/oggparseflac: Fix memleaks in old_flac_header()
[03:55:53 CEST] <cone-681> ffmpeg 03Michael Niedermayer 07master:5db111757c89: avformat/movenc: Rename reshuffles return variable to ensure it is not mixed up
[03:55:54 CEST] <cone-681> ffmpeg 03Michael Niedermayer 07master:86d703fd5584: avformat/movenc: Fix memleak of reshuffled packet
[12:00:46 CEST] <cone-506> ffmpeg 03Carl Eugen Hoyos 07master:a64a030ba0d1: lavf/mov: Support one more Avid compression id for AVCI50.
[13:21:15 CEST] <omerjerk> Any idea how do I check if a SoftFloat equals a particular number or not. 
[13:21:37 CEST] <omerjerk> I've a SoftFloat object, and I need to check it whether it is equal to 1.0f or not.
[13:21:46 CEST] <omerjerk> Any help would be appreciated. 
[13:27:54 CEST] <kierank> why are you using softfloats?
[13:29:39 CEST] <omerjerk> I've floats in my code and I need to avoid them using SoftFloats. 
[13:29:57 CEST] <omerjerk> I also need the exp and mantissa data of the floats at various places. 
[13:32:14 CEST] <kierank> ok
[13:33:21 CEST] <omerjerk> so, any idea ?
[13:38:13 CEST] <kierank> may have to write your own helpers for that
[13:38:22 CEST] <kierank> coeff and mantissa checks
[13:48:23 CEST] <michaelni> omerjerk, av_cmp_sf() 
[13:50:29 CEST] <omerjerk> michaelni, I did see that function. Suppose I convert 1.0f also to a Softfloat. 
[13:51:03 CEST] <omerjerk> What is the expected output of av_cmp_sf(soft_float_to_check, one_soft_float); ?
[13:51:16 CEST] <michaelni> you can use FLOAT_1
[13:51:30 CEST] <omerjerk> okay, but what's the expected output ?
[13:51:40 CEST] <michaelni> i thought it was documented, i guess i should document it if its not
[13:51:40 CEST] <omerjerk> in case the SoftFloat is actually 1 ?
[13:52:13 CEST] <michaelni> i think FLOAT_1 is 1.0 yes
[13:52:53 CEST] <omerjerk> okay, but what would be the return value of av_cmp_sf function ?
[13:53:14 CEST] <michaelni> 0 probably, ill RTFS to double check and document this properly
[13:54:41 CEST] <omerjerk> okay. thanks a lot! I'll test my code and reply here. 
[13:57:19 CEST] <omerjerk> Also, what is the frac_bits parameter for in the av_int2sf() function ?
[14:01:25 CEST] <omerjerk> michaelni, ?
[14:02:03 CEST] <michaelni> this one seems documented: @returns a SoftFloat with value v * 2^frac_bits
[14:07:52 CEST] <omerjerk> There's nothing like that documented here - https://www.ffmpeg.org/doxygen/2.2/softfloat_8h_source.html
[14:09:46 CEST] <michaelni> https://www.ffmpeg.org/doxygen/trunk/softfloat_8h_source.html
[14:26:23 CEST] <cone-506> ffmpeg 03Michael Niedermayer 07master:d1520a6cfd81: avutil/softfloat: Document public constants and a few public functions
[14:29:12 CEST] <michaelni> nevcairiel, about AVClass/AVOptions, iam not sure i understood your objection about AVCodecParameters 
[14:30:51 CEST] <michaelni> I think we should consistently support it in the main public API structures like AV*Context AVFrame AVStream, ... 
[14:31:39 CEST] <nevcairiel> and I don't think its useful for API users
[14:31:49 CEST] <nevcairiel> it loses the type safety of C, which is never a good thing
[14:32:37 CEST] <nevcairiel> its somewhat a necessity for private options on AV*Context dealys
[14:32:41 CEST] <michaelni> how does it loose type saftey ? 
[14:32:51 CEST] <nevcairiel> but simple data structures like AVFrame or AVPacket just don't need it for nothing
[14:33:06 CEST] <michaelni> the AVOptions list the types 
[14:33:52 CEST] <nevcairiel> and you can still use a string to set it, or get a string back from a int option
[14:34:21 CEST] <michaelni> theres av_opt_set_int()
[14:34:48 CEST] <michaelni> av_opt_get_int()
[14:34:53 CEST] <nevcairiel> I just don't see how thats any kind of advantage over accessing the struct itself
[14:35:07 CEST] <nevcairiel> you have to enumare options programmatically to get that information
[14:35:16 CEST] <nevcairiel> which means a developer has to run code to figure out how to write code
[14:35:45 CEST] <nevcairiel> (or go read the code, which is not distributed with the installed headers)
[14:36:32 CEST] <michaelni> the advantage is for applications which try to support a wider range of lib versions for example or to for example build a GUI list of the available options
[14:36:58 CEST] <nevcairiel> AVFrame and AVPacket don't have options
[14:37:03 CEST] <michaelni> for example sample_rate might be changed to AVRational one day or channel_layout might become more than a 64bit bitmask 
[14:38:57 CEST] <michaelni> true about AVFrame/Packet it could still help apps trying to support multiple distros and old versions though
[14:39:39 CEST] <michaelni> also AVFrame has AVClass & AVOption avcodec_get_frame_class()
[14:40:25 CEST] <nevcairiel> maybe we should just include some helper macros to give them a standardized way to check versions, instead of shoving these objects into every single struct
[14:41:11 CEST] <nevcairiel> supporting multiple ABIs from the same binary is never going to really fly
[14:41:17 CEST] <michaelni> iam not sure what you suggest, iam just scared of the kind of code we ended up in mplayer to support only a small number of versions long ago
[14:41:49 CEST] <michaelni> it was really ugly #if VERSION this version that and dozends such lines
[14:43:02 CEST] <nevcairiel> avoptions only cover a minority of the changes either way, there is plenty API changes you still need that for
[14:43:38 CEST] <michaelni> avoptions in AVCodecContext/Format fixed most of it IIRC
[14:44:44 CEST] <michaelni> it would still be needed for avcodec_decode_audio/video123456789() of course
[14:45:28 CEST] <michaelni> and thats also why iam always unhappy support for these things get droped :)
[14:46:39 CEST] <michaelni> its not that it personally affects me i dont maintain any affected code, i just had worked on and saw this in the past
[15:47:46 CEST] <michaelni> nevcairiel, the AVClass/AVOption vs. something else vs. nothing question needs to be awnsered before the release, as AVCodecParaeters cannot be changed afterwards easily
[17:32:28 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vr9Nc
[17:32:28 CEST] <KGB> 13FFV1/06master 14fd03170 15Jérôme Martinez: More explicit version tests...
[18:58:29 CEST] <saste> durandal_170, what about creating #ffmpeg-meeting and updating the topic here to point to the new channel
[18:58:36 CEST] <saste> better to have a dedicated channel
[18:59:00 CEST] <durandal_170> sure
[18:59:45 CEST] <durandal_170> saste: but someone is already there...
[19:01:34 CEST] <BBB> durandal_1707: then create another channel?
[19:02:10 CEST] <durandal_170> ffmpeg-meeting2016
[19:05:14 CEST] <BBB> oh youre operator in #ffmpeg-meeting also now
[19:05:16 CEST] <BBB> weird
[19:05:16 CEST] <BBB> anyway
[19:05:19 CEST] <BBB> do as you pelase
[19:05:21 CEST] <BBB> *please
[19:05:36 CEST] <saste> BBB I asked c_14 to move ops to durandal
[19:07:56 CEST] <saste> durandal_170, please state where the meeting should be held and let's start
[19:09:00 CEST] <jamrial> those who confirmed would come are already there. we could wait a bit more to see if someone else shows up
[19:09:02 CEST] <durandal_170> saste: its ffmpeg-meeting2016
[19:09:16 CEST] <durandal_170> could you update topic here?
[19:09:38 CEST] <saste> durandal_170, yes
[19:10:20 CEST] <michaelni> durandal_170, also please set topic in the other channel to point to the used channel
[19:11:16 CEST] <michaelni> so noone mistakley sits there waiting not realizing that ffmpeg-meeting2016 is used
[19:11:29 CEST] <michaelni> durandal_170, thx
[19:13:00 CEST] <saste> will send an email to ffmpeg-devel with the channel info
[22:33:00 CEST] <DHE> I have a suspect in the mpeg-ts wrap mystery
[22:33:25 CEST] <cehoyos> A sample would be better;-)
[22:34:10 CEST] <DHE> sadly you actually need a 26.5 hour sample. so I'd have to generate something really outrageous (like .01fps video or something)
[22:34:27 CEST] <cehoyos> Maybe you can tell us how to create the sample?
[22:34:40 CEST] <JEEB> DHE: try grabbing first an hour around the wraparound point
[22:34:50 CEST] <DHE> umm... I actually recorded an OTA feed for over a day. It's about 90 GB large
[22:34:59 CEST] <JEEB> if that doesn't make it happen then you are sadface
[22:35:08 CEST] <cehoyos> JEEB: I believe FFmpeg completely hides the issue (what issue?) in that case.
[22:35:20 CEST] <JEEB> it *should*
[22:35:26 CEST] <JEEB> as in the usual mpeg-ts wraparound
[22:35:26 CEST] <DHE> JEEB: I think it's actually bad logic in the wrap handling. even though the timestamps don't start at 0 (live streams will pick up at any point) it's when the timestamp passes its own starting point
[22:35:33 CEST] <cehoyos> I suspect it does (at least for file input)
[22:36:04 CEST] <JEEB> hmm
[22:36:13 CEST] <DHE> if you start at a timestamp of "10h5m" (for the sake of being arbitrary) and then run into "26h30m + 1s == 0s" it's properly wrapped to "26h30m1s"
[22:36:26 CEST] <JEEB> right
[22:36:58 CEST] <DHE> but when you eventually come back around to "10h5m" it stops wrapping. The client expects "36h35m" but gets back "10h5m" again
[22:37:42 CEST] <JEEB> I should really get my OTA/satellite setup fixed in august ;)
[22:37:44 CEST] <nevcairiel> yeah i dont think it handels such long running timestamps
[22:37:58 CEST] <cehoyos> I suspect mpegts does not support "36h35m"
[22:38:17 CEST] <nevcairiel> mpegts handles infinity, its for broadcasts, those dont stop
[22:38:44 CEST] <JEEB> yeah, you just have to handle the timestamp wraparound correctly. this sounds like it happens in the logic after that
[22:38:55 CEST] <cehoyos> But it never shows "36h35m" but "10h35m" as often as necessary depending on the length of the file, or do I misremember?
[22:39:07 CEST] <DHE> it doesn't. libavformat/utils.c has code to do the wrap-around and mpegts announces its PTS wraparound policy correctly. utils.c is just mishandling it
[22:39:13 CEST] <DHE> I'm still debugging, so gimme a few minutes
[22:40:00 CEST] <nevcairiel> from what I remember how wraparound in utils.c works, it only allows one wrap, and only up to the maximum of time the timestamp precision can account for
[22:41:50 CEST] <DHE> that seems to be about right
[22:43:02 CEST] <DHE> since pts and dts can vary, you can end up with both of them on distinct halves of the wraparound point (which is the timestamp reading at the time of joining the stream). this can result in pts < dts right out of av_read_frame()
[22:43:39 CEST] <DHE> cur_pkt = {pts = 1357514296, dts = 9947433873, ... }
[22:44:18 CEST] <cehoyos> Please provide such a sample
[22:44:59 CEST] <DHE> This should be interesting...
[22:45:03 CEST] <JEEB> we'll have to see how simple the case is to make a small sample of :P
[22:45:16 CEST] <cehoyos> The sample does not have to be small...
[22:50:36 CEST] <DHE> well I'm not giving you my 90 GB sample either
[22:50:40 CEST] <Illya> cehoyos: Uploading 90GB sample isn't particularly practical though
[22:50:53 CEST] <Illya> Uploading a*
[22:51:49 CEST] <cehoyos> So far, 10G was the biggest sample, is 24h SD channel really 90G?
[22:52:35 CEST] <DHE> who said it was SD?
[22:52:43 CEST] <DHE> :)
[22:52:49 CEST] <DHE> it's ~7.5 megabit HD
[22:53:10 CEST] <cehoyos> The issue is not reproducible with an SD channel?
[22:53:15 CEST] <rcombs> clip just the bits close to the wraparounds?
[22:53:18 CEST] <cehoyos> (DVB-T)
[22:53:24 CEST] <rcombs> in theory that should repro the issue just as well
[22:53:34 CEST] <cehoyos> I don't think so.
[22:53:34 CEST] <rcombs> since mpegts can resync you could even do it bytewise
[22:53:39 CEST] <DHE> rcombs: doesn't work that way. the bug manifests when wraparound occurs and the PTS/DTS returns to its starting point when ffmpeg was launched
[22:53:49 CEST] <DHE> actually that's not a bad idea...
[22:54:01 CEST] <JEEB> yeah
[22:54:02 CEST] <DHE> I could literally crop out everything else
[22:54:07 CEST] <JEEB> aye
[22:54:17 CEST] <cehoyos> DHE: Please send an email to the user mailing list with command line and complete, uncut console output; I will then try to reproduce.
[22:54:27 CEST] <rcombs> probably would show up weird in an actual player but who cares
[22:55:26 CEST] Action: DHE is getting byte offsets first for the cutting
[22:55:36 CEST] <DHE> the dev list?
[22:57:09 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vrHLj
[22:57:09 CEST] <KGB> 13FFV1/06master 14c1cf473 15Jérôme Martinez: Slice structure clarification...
[22:57:21 CEST] <Illya> user mailing list, unless you have a fix for it (I think)
[22:57:53 CEST] <DHE> I have 2 patches under Git to my name. I might be able to fix this...
[23:21:38 CEST] <DHE> I have a few ideas for solutions, but they tend to not be so hot in the face of bad input (and I've seen bad input)
[23:22:35 CEST] <JEEB> breaking on bad input is less bad than breaking on valid input
[23:22:49 CEST] <JEEB> also it depends on the level of badness etc
[23:22:51 CEST] <nevcairiel> unless its breaks spectacularly  worse than before
[23:24:16 CEST] <DHE> well, I have a custom libav* app that (tries to) deal with this. I have a record of the last dts. while (recevied_dts < last_dts) received_dts += wrap_period;  
[23:24:33 CEST] <DHE> and then while (pts < dts) pts += wrap_period;
[23:25:02 CEST] <DHE> but a little bit of DTS inconsistency/error and this could produce bad numbers
[23:28:16 CEST] <DHE> the concept could be improved to not actually loop, but I figured 1 iteration per day of processing was small enough to be ignored
[00:00:00 CEST] --- Sun May 29 2016