[00:30] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:4260ed462b4c: avcodec/h264_cabac: fix indention [00:31] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:e31727bd53fc: avcodec/mjpegdec: make type of shift unsigned to avoid undefined behavior [00:31] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:d80e7ba9b7de: ffmpeg_filter: make *jpeg_formats static const [02:32] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:2cf514354bbe: avcodec/mpeg12enc: increase declared size of block function argument [04:57] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:18af0ce62da3: avfilter/graphdump: Fix pointer to local outside scope [08:24] <anshul_> cehoyos, why is it hard to believe? [10:03] <j-b> good morning [13:38] <BBB> hi j-b [14:00] <mraulet> michaelni: how to update sequences on fate? [14:26] <j-b> hello BBB [14:26] <BBB> \o/ [14:27] <BBB> so, when's ny going to welcome you, dear sir? [14:28] <BBB> oh work, gtg, later [14:40] <michaelni> mraulet, make fate-rsync [14:40] <mraulet> no in the opposite [14:40] <mraulet> I have new sequences [14:41] <mraulet> and some that I need to remove [14:41] <nevcairiel> if those removed ones were used in tests before, they should remain on the fate system so that older tests in eg. release branches remain functional [14:42] <michaelni> to add new ones, post a link to what should be added and a path to where exactly it should be added [14:43] <mraulet> https://github.com/OpenHEVC/FFmpeg/commit/df245c6c1a5f21ecf646f500c20c5fcd99... [14:43] <mraulet> https://github.com/OpenHEVC/FFmpeg/commit/afa7c81ed4ad312d6a4266c2194392923d... [14:44] <mraulet> I can give you a link to those sequences [14:44] <mraulet> nevcariel: if they have been removed from jct-vc, there is good reasons [14:45] <mraulet> so I suppose fate should do the same [14:45] <nevcairiel> well fact remains that old release branches would then fail as they are missing the samples [14:45] <nevcairiel> if there is a good enough reason might as well patch the release fate tests [14:46] <michaelni> removial is not possible [14:46] <mraulet> oh pfiou [14:46] <michaelni> it would break git bisect [14:46] <nevcairiel> that too [14:46] <nevcairiel> you can stop testing them of course [14:46] <nevcairiel> just the samples should stay [14:46] <mraulet> ah ok [14:46] <mraulet> this looks better [14:53] <smarter> hey mraulet [14:54] <smarter> some of these streams are already in FATE, like tests/ref/fate/hevc-conformance-LS_B_ORANGE_4 [14:57] <smarter> I think only bitstreams which are less than 3 months old haven't been added yet [14:58] <mraulet> smarter: I notice the issue for Orange_4 [14:58] <smarter> mraulet: by the way, did you implement pic_output_flag? It's needed for OPFLAG_B_Qualcomm_1 and OPFLAG_C_Qualcomm_1 [14:58] <mraulet> yes [14:58] <smarter> ah cool [14:59] <mraulet> it is part of one patch here [14:59] <mraulet> I have not added bumping process since we cannot support it [14:59] <smarter> I don't see pic_output_flag support in the commits you linked [15:00] <mraulet> https://github.com/OpenHEVC/FFmpeg/commit/2cf2cfdd10cf67090bb9ab9c7bcda8a605... [15:01] <smarter> okay, so if you have other changes like these, they should be merged first before adding the new streams to FATE [15:01] <mraulet> yes [15:03] <mraulet> we will redo the patches and provide a link to the new sequences [15:56] <cone-834> ffmpeg.git 03Michael Niedermayer 07master:4394f82f5258: avformat/utils: add gif to tb_unreliable() [15:56] <cone-834> ffmpeg.git 03Michael Niedermayer 07master:1f249d2ca725: avformat/utils: prevent r frame rate from being set larger than 1/tb [16:48] <cone-834> ffmpeg.git 03Anton Khirnov 07master:1eb57e1d9b59: lavc: eliminate tb_unreliable() [16:48] <cone-834> ffmpeg.git 03Michael Niedermayer 07master:502a8f56b9f7: Merge commit '1eb57e1d9b59db0aa63348c21bf3290bd3f5efcb' [16:48] <cone-834> ffmpeg.git 03Michael Niedermayer 07master:34e7d3c3681a: avformat/utils: Ensure that average fps is probed if requested by the user even if tb_unreliable() is 0 [16:50] <ubitux> michaelni: about tb_unreliable i might have a clue of why it's been applied [16:50] <michaelni> yes? [16:50] <ubitux> i'll paste a log in a moment [16:50] <ubitux> need to dig that again [16:55] <ubitux> michaelni: http://b.pkh.me/tb_unreliable.log [16:56] <ubitux> this was just before the patch was sent, i guess it's related [17:10] <michaelni> thx [17:10] <michaelni> also if anyone has any testcases where libav provides better fps values by default, please ping me [17:13] <nevcairiel> elenril with his obsession with vfr, not considering the 99% of all cases which are not :p [17:15] <Daemon404> that value is probably lower with the advent of smartphones [17:15] <Daemon404> which all capture vfr [17:16] <nevcairiel> mine doesnt [17:16] <Daemon404> all apple ones do [17:16] <Daemon404> and many android [17:16] <Daemon404> (iirc) [17:16] <nevcairiel> i havent had an android phone which did vfr [17:16] <nevcairiel> either 30 or 60, but not variable [17:16] <Daemon404> maybe its just apple [17:19] <JEEB> nah, at least two of my android phones do VFR [17:20] <JEEB> although mostly in cases when they can't keep up [17:21] <nevcairiel> does it really go vfr and slow down to a lower fps, or just skip a frame here and there? [17:22] <JEEB> skipping methinks, it still ends up being VFR timestamp-wise though [17:24] <nevcairiel> well sure, but the target pretty much remains say 30 fps, it just couldn't keep up and leaves a few "holes", all frames which did make it still fit the 30 fps timestamp chain .. with holes [17:54] <ubitux> michaelni: i don't understand what this tb change for gif fixes [17:54] <ubitux> can you elaborate? [17:55] <ubitux> current demuxer set a 1/100 tb, after your change the samples go from 1/100 to 1/10 (which seems enough to represent every ts, right) [17:56] <michaelni> r_frame_rate before was 100 after the change its 10 [17:57] <michaelni> 10 is more "tighter" [17:57] <michaelni> fewer duplicated frames with cfr output [17:58] <michaelni> actually none id assume [17:59] <ubitux> ah ok [18:00] <ubitux> and so if at some point in the gif you get a ts making use of the 1/100 tb, this won't be changed to 1/10 right? [18:00] <michaelni> if its within the frames that are probed, yes [18:00] <ubitux> mmh ok [18:01] <michaelni> a user app can always use the timebase instead of r_frame_rate [18:01] <michaelni> if it wants to be sure that all timestamps can be represented excatly [18:01] <ubitux> ok [18:02] <Daemon404> correction: They *should* be using the timebase [18:03] <michaelni> yes, but sometimes they just cannot, like for cfr output with a 1/1000000 tb [18:59] <cone-834> ffmpeg.git 03Michael Niedermayer 07master:a215b158152e: avformat/utils: Set the average frame rate from the r_frame_rate if the stream appears to be cfr [19:04] <Daemon404> that seems like it could be a horrible idea... [19:06] <michaelni> Daemon404, why? [19:06] <Daemon404> because it is using a heuristic [19:06] <michaelni> what ? [19:07] <Daemon404> a heuristic to detemrine if it is cfr [19:08] <michaelni> avg_frame_rate is purely a heuristical guess [19:08] <Daemon404> are you saying heuristic to detemrine if it is cfr [19:08] <Daemon404> er [19:08] <Daemon404> fail [19:08] <Daemon404> damn tty [19:08] <Daemon404> what i meant: [19:09] <Daemon404> are you saying avg_frame_rate is not the avg frame rate? [19:09] <Daemon404> i.e. based on the average [19:09] <nevcairiel> for most formats you wouldn't know the absolute average until you're done reading the file [19:09] <michaelni> nevcairiel, yes [19:09] <nevcairiel> so instead, you guess [19:09] <Daemon404> right [19:10] Action: Daemon404 should fasttrack his plans to move to his own fps code [19:10] <michaelni> yes and the new code isnt doing anything more evil than that [19:10] <Daemon404> based off of preindexing the file [19:10] <nevcairiel> I wish i could afford pre-indexing a file [19:10] <nevcairiel> but alas, yay playback [19:10] <Daemon404> yeah [19:11] <nevcairiel> to be fair i dont really worry about the fps value much either way [19:11] <nevcairiel> hoping for timestamps [19:11] <Daemon404> matters to me :P [19:11] <nevcairiel> that reminds me that i've had a few files recently which had screwed up h264 timestamps, i wanted to check out what happened to them... [19:12] <nevcairiel> (ts files) [19:13] <michaelni> Daemon404, do you have files that produce a bad fps value ? [19:13] <michaelni> if so i would be interrested and will take a look at them later [19:13] <Daemon404> ltos, but not indexed for me to find in any meaningful way [19:13] <Daemon404> lots* [19:13] <Daemon404> mostly because an average over a duration is not inherently useful [19:13] <Daemon404> for certain sorts of vfr files [19:14] Action: Daemon404 's code uses other fancy like LCM and stuff over the preindexed file [19:15] <michaelni> is the r_frame_rate bad too ? [19:15] <michaelni> also either way, id like to see the files [19:15] <Daemon404> on some files yes [19:15] <Daemon404> choosing a "good" framerate requires preindexing IMO [19:16] <Daemon404> simple stuff liek checking for ridiculous timestamp delta outliers [19:16] <Daemon404> as an example. [19:16] <michaelni> yes, you need preindexing if you want a perfect value in all cases [19:16] <Daemon404> yep [19:16] <Daemon404> thats what im currently doing [19:17] <michaelni> still iam hoping to be able to improve the non preindex code if possible [19:17] <michaelni> because preindex is not always an option [19:17] <michaelni> not an option for some people / cases [19:17] <Daemon404> yes [19:17] <Daemon404> like nevcairiel [19:18] <nevcairiel> havent had much complaints recently anymore though about bad values [19:18] <Daemon404> for the non-preindexed version [19:18] <Daemon404> it may help if the file can be accurately (or semi accurately) seeked [19:18] <Daemon404> i.e. use a few windows for analysis [19:19] <Daemon404> not sure if ffmpeg does this currently [19:19] <nevcairiel> i think it just analyses a window at the start of the file [19:19] <Daemon404> yeah thats what i assumed [19:19] <Daemon404> i have a lot of files with e.g. the ending credits are 30fps [19:19] <Daemon404> rest is 24 [19:20] <michaelni> need to leave, ill be back in 30min or so, please provide some failing files (i dont have any AFAIK) [19:20] <Daemon404> should be relatively easy to create one [19:21] <Daemon404> ill try in a bit [19:21] <nevcairiel> personally, for my own goals and whatnot, i would prefer 24 fps as the information for such a file, who cares if the ending credits stutter then :p [19:22] <Daemon404> well yes [19:22] <Daemon404> consider a case where analyse duration is all 24 fps (e.g. an opening credits) [19:22] <Daemon404> but the rest of teh file is 3 hrs of 30fps [19:23] <Daemon404> you wanna be a bit smarter if converting to cfr [19:24] <nevcairiel> i guess, but its all more heuristics, and slows down opening significantly [19:27] <nevcairiel> we should all just switch to mp4 [19:27] <nevcairiel> where every timestamp ever is in the header [19:39] <wm4> such a stupid format [19:40] <nevcairiel> i really like that about mp4, decoupling all metadata from actual media data [19:44] <wm4> I think well designed media formats should be naturally streamable, and some properties of mp4 make this hard [19:45] <Daemon404> [18:27] <+nevcairiel> where every timestamp ever is in the header [19:45] <Daemon404> or more usually: the tail [19:46] <Plorkyeran> naturally streamable and easy to seek in are unfortunately somewhat mutually exclusive [19:47] <Daemon404> and then you have ogg [19:47] <Daemon404> which is neither [19:47] <wm4> Daemon404: but is used for both anyway! [19:47] <wm4> (why wasn't ogg killed yet?) [19:48] <Daemon404> because xiph uses it for every new thng [19:48] <Daemon404> daala is using ogg too [19:48] <Daemon404> hell, their ssim tool has a harp dep on libogg [19:48] <Daemon404> hard* [19:49] <nevcairiel> Daemon404: well head or tail, but in one dedicated easy-to-find block! [19:50] <Daemon404> and if its not there [19:50] <Daemon404> youre fucked [19:50] <wm4> at least they should attempt to make its design cleaner (i.e. full redesign + keep name/file ext.) [19:50] <Daemon404> forgot the last few kb of the time? [19:50] <Daemon404> hahahaHAHAHAHAHA enjoy [19:50] <Daemon404> of the file* [19:50] <nevcairiel> well, but then the whole file doesn't work, and you dont have to worry about fps [19:50] <Daemon404> ive been left with 5 gb mp4s missing a few kb at the end [19:50] <Daemon404> rendered entirely useless [19:50] <Daemon404> great format [19:51] <nevcairiel> i suppose its easier to lose a few kbs at the end than at the start [19:51] <Plorkyeran> should make a format where the contents are encrypted using the hash of the file as the key [19:52] <Plorkyeran> to ensure that a single corrupted bit stops you from opening the file [19:52] <Plorkyeran> to one-up mp4 [19:52] <Daemon404> or just make the fire entirely bitpacked [20:23] <cone-834> ffmpeg.git 03James Almer 07master:096de451b0f9: configure: add support for new CPUs [20:24] <michaelni> smarter, mraulet, do you know if " [FFmpeg-devel] [PATCH] avcodec/hevc_cabac: decrease CABAC_MAX_BIN" is ok ? [20:29] <smarter> michaelni: I think it should be ok [20:30] <michaelni> smarter, ok thx [20:30] <smarter> michaelni: it seems that CABAC_MAX_BIN could be 32, since the checks are always k < CABAC_MAX_BIN [20:30] <smarter> mraulet: do you see anything wrong with this change: https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2014-April/157091.html ? [20:31] <michaelni> smarter, i think with 32 it will shift into the sign bit somewhere [20:35] <michaelni> ff_hevc_cu_qp_delta_abs could be changed to unsigned but mvd_decode() needs signed output [20:36] <smarter> michaelni: ah you're right [20:36] <smarter> so the patch should be fine [20:38] <kurosu> what's that max for? max length of a specific syntax element, eg mvd ? [20:38] <kurosu> s/a specific/any, actually [20:41] <kurosu> seems so [20:43] <cone-834> ffmpeg.git 03Michael Niedermayer 07master:812066835189: avcodec/hevc_cabac: decrease CABAC_MAX_BIN [21:19] <mraulet> openhevc already have it to 32bits [22:35] <wm4> michaelni: note that libav just broke the build with the dxva patch, so maybe you shouldn't merge that yet [00:00] --- Tue Apr 29 2014