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

[burek]

[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/df245c6c1a5f21ecf646f500c20c5fcd99b2ea7e
[14:43] <mraulet> https://github.com/OpenHEVC/FFmpeg/commit/afa7c81ed4ad312d6a4266c2194392923d6dbcd3
[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/2cf2cfdd10cf67090bb9ab9c7bcda8a605f81d0d
[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