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

[burek]

[00:00:01 CEST] <BBB> I think I asked that before
[00:00:28 CEST] <jamrial> also, websites like vlc's defaulting to 32 bits builds and requiring the user to click and browse through four pages to get a 64 bits build doesn't help either
[00:01:00 CEST] <nevcairiel> i work for a company making a commercial media management solution .. ie. a glorified player with a file database
[00:02:21 CEST] <nevcairiel> and there is of course my open-source plugin based on avformat and avcodec which integrates both into the DirectShow framework, used by a large variety of windows players
[00:02:54 CEST] <BBB> I sometimes forget that windows still exists
[00:02:57 CEST] <BBB> these blissful moments
[00:03:16 CEST] <llogan> then it pops up back into your life like a lip herpy
[00:03:41 CEST] <nevcairiel> i've been pushing for work to at least start offering a 64-bit version with a big notice that plugins wouldnt work, but its complicated
[00:08:01 CEST] <BBB> llogan: I just close my eyes and pretend it didnt happen :-p
[00:13:25 CEST] <friki2015> (offtopic?) the seek time on a video depends on the length of the jump, isn't it?
[00:14:06 CEST] <nevcairiel> generally, no
[00:14:58 CEST] <friki2015> so, i'll redo my yesterday tests
[00:15:00 CEST] <nevcairiel> most seekable formats would have an index for direct seeking, or at least directly readable timestamps for a binary search
[00:15:21 CEST] <nevcairiel> some formats are not really designed for seeking, so they may behave differently
[00:16:22 CEST] <friki2015> by default a ffmpeg encoded video should bee "direct seekable"? (i dont' remenber exaclti... h264+aac+(flv/ts) )
[00:16:37 CEST] <nevcairiel> it depends on the format
[00:16:45 CEST] <nevcairiel> both flv and ts are not very good formats for file storage
[00:17:02 CEST] <nevcairiel> ts is for streaming/broadcasting, and flv is just generally bad :p
[00:17:05 CEST] <nevcairiel> use mp4 or mkv
[00:17:37 CEST] <friki2015> thanks
[00:19:19 CEST] <friki2015> i plan to seek very long videos (max 1 week)
[00:22:36 CEST] <llogan> atomnuker: pushed the ffserver news
[00:22:51 CEST] <atomnuker> llogan: saw, thanks
[00:59:50 CEST] <BBB> friki2015: the seek time (for exact seeking) generally depends on the distance to the preceeding i frame. if seeking to a i frame, the seek time should be near-instant unless something else buggers you (player overhead, playback decoded frame cache, network latency for non local files, etc.)
[01:00:31 CEST] <BBB> friki2015: for some file formats without indices (seekcache in matroska parleance), seeking is much more complex
[02:57:30 CEST] <friki2015> BBB: thanks, i'm working to build a 1 week video in order to test disctinct file formats. i really don't care about the fileformat if it can seek fast on very big videos
[03:03:26 CEST] <Compn> ehe
[03:03:34 CEST] <Compn> i bet there are a lot of time limits hidden in various demuxers
[03:03:52 CEST] <Compn> but people have been streaming for weeks so maybe not
[06:05:25 CEST] <bp0> have you heard of slow tv in norway?
[06:05:39 CEST] <bp0> friki2015
[06:05:45 CEST] <bp0> sorry that was 3 hours ago
[06:06:25 CEST] <bp0> anyway, it is hours long or days long video of something uncut, like a train journey or a cruise, or burning firewood
[06:06:41 CEST] <bp0> broadcast on public tv
[08:35:06 CEST] <cone-134> ffmpeg 03Vignesh Venkatasubramanian 07master:acca56d9629b: libvpx: Enable vp9 alpha encoding
[13:17:45 CEST] <robUx4> nevcairiel: have you tried VP9 Profile 1 (10 bits) with the DXVA2 Profile 0 decoder ?
[13:17:54 CEST] <robUx4> and VP8 ?
[13:19:14 CEST] <nevcairiel> the decoders support exactly the profile they advertise, trying to decode anything else is futile
[13:21:02 CEST] <robUx4> ok
[14:08:38 CEST] <friki2015> bp0: never heard about it... in spain when we need to take a snap we just watch 'Le Tour' ;)
[14:09:34 CEST] <friki2015> my 1 week records will be some think similar to a security cam record
[14:40:21 CEST] <mateo`_> michaelni: i've updated my libav-merge branch (https://github.com/mbouron/FFmpeg/commit/2cd0ad839d2ea4c77ee21cf8ca89e61e8f45512a), the first crash is fixed, the regression while playing http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket1918/aark15sd_9A62E2FA.mp4 not yet, because some stsc entries (1503-1800~)from this file seems corrupt and the merge adds a check on those values (they must not be greater
[14:40:23 CEST] <mateo`_> than sc->stsd_count)
[14:42:14 CEST] <mateo`_> should I drop compatibility with this file *or* should i drop the check and improve/harden the new code that rely on sc->stsc[index].id to deduct the stsd id
[14:47:50 CEST] <mateo`_> second proposition sounds better (imho)
[15:00:31 CEST] <cone-567> ffmpeg 03Martin Vignali 07master:f2b08a07028e: libavcodec/exr : cosmetics, rename variable in b44_uncompress func
[15:01:02 CEST] <michaelni> mateo`_, i agree 2nd sounds better
[15:05:25 CEST] <mateo`_> should the fix be separate commit ?
[15:05:52 CEST] <nevcairiel> ideally master should never be broken
[15:06:39 CEST] <mateo`_> ok, i'll document the changes i made in the commit message then
[15:13:48 CEST] <michaelni> mateo`_, theres a crash remaining, ill sent you the sample to repro
[15:14:18 CEST] <mateo`_> thanks
[16:15:13 CEST] <mateo`_> michaelni: i've updated the branch
[16:38:45 CEST] <ubitux> i'll start back the merging effort in the next days
[16:41:37 CEST] <mateo`_> michaelni: regarding the sample you provided, it seems there is regression between 3.0.2 et current master, ie: the sample does not play as it did before
[16:42:32 CEST] <michaelni> mateo`_, which sample ?
[16:42:55 CEST] <mateo`_> the one you sent to me
[16:43:22 CEST] <mateo`_> the private one to be more precise
[16:44:09 CEST] <michaelni> it doesnt need to play, its not a valid h264 stream
[16:44:33 CEST] <mateo`_> it did before
[16:45:12 CEST] <mateo`_> anyway, i'll push the merge commit in a few minutes
[16:46:25 CEST] <michaelni> i see what you mean about the sample
[16:55:02 CEST] <cone-567> ffmpeg 03Vittorio Giovara 07master:76729970049f: mov: Implement support for multiple sample description tables
[16:55:03 CEST] <cone-567> ffmpeg 03Matthieu Bouron 07master:3c058f570128: Merge commit '76729970049fe95659346503f7401a5d869f9959'
[17:06:44 CEST] <cone-567> ffmpeg 03Vittorio Giovara 07master:846a3e78a535: mov: Support prores with multiple stsd
[17:06:45 CEST] <cone-567> ffmpeg 03Matthieu Bouron 07master:354336490da0: Merge commit '846a3e78a535f05ee61bb23a160f3378f041f751'
[17:14:15 CEST] <cone-567> ffmpeg 03Matthieu Bouron 07master:495a40cecb4d: tests/checkasm: reduce cosmetic diff with libav
[17:23:14 CEST] <cone-567> ffmpeg 03Martin Storsjö 07master:105998fb5ca3: checkasm: Add tests for h264 idct
[17:23:15 CEST] <cone-567> ffmpeg 03Matthieu Bouron 07master:a91c330a29f3: Merge commit '105998fb5ca3c343f5c8cb39ce3197f87a5e4d36'
[17:26:20 CEST] <mateo`_> michaelni: does our ffv1 decoder support transparency ?
[17:28:49 CEST] <mateo`_> I'm looking at the next merge (ec9f044 ffv1: Error out on unsupported format)
[17:29:13 CEST] <mateo`_> sorry the question would be more like does it support transparency with format other than yuv
[17:30:29 CEST] <michaelni> i see AV_PIX_FMT_RGB32 in there
[17:30:38 CEST] <michaelni> thats with alpha
[17:32:35 CEST] <mateo`_> mmm, I wonder if this commit should be a noop
[17:32:57 CEST] <michaelni> probably
[17:34:17 CEST] <michaelni> is this supposed to be a reimplementation of 878c3a36451eaf1ae3ec3d8eab0af11dab0a7695 ?
[17:35:26 CEST] <jamrial> mateo`_: can i push something or will it force you to locally rebase your work?
[17:36:44 CEST] <mateo`_> jamrial: you can push
[17:36:48 CEST] <mateo`_> thanks for askin ;)
[17:36:50 CEST] <mateo`_> +g
[17:37:42 CEST] <cone-567> ffmpeg 03James Almer 07master:fde9c5e42430: fate: fix fate-vp8 dependencies
[17:37:55 CEST] <jamrial> mateo`_: no prob
[17:41:19 CEST] <cone-567> ffmpeg 03Jerome Martinez 07master:ec9f04423b82: ffv1: Error out on unsupported format
[17:41:20 CEST] <cone-567> ffmpeg 03Matthieu Bouron 07master:57fa9608e419: Merge commit 'ec9f04423b82afa323e90f5b2c677be74302c1fd'
[17:55:15 CEST] <BBB> vp9_inv_dct_dct_32x32_add_8_avx: 2690.9
[17:55:15 CEST] <BBB> vp9_inv_dct_dct_32x32_add_8_avx2: 1572.9
[17:55:23 CEST] <BBB> sweet
[17:55:41 CEST] <BBB> so thats 1.7x
[17:56:17 CEST] <BBB> (for the full idct; I didnt do sub-idcts yet)
[17:58:19 CEST] <mateo`_> durandal_1707: http://0x5c.me/diff.html should i take all their changes ?
[17:58:58 CEST] <mateo`_> durandal_1707: nevermind, this diff is not relevant
[18:01:45 CEST] <mateo`_> durandal_1707: i've updated the diff comparing their commit and the current magicyuv.c code in master
[18:03:15 CEST] <ubitux> #include "../libavutil/pixdesc.h"  you don't want the "../" here
[18:03:23 CEST] <ubitux> and you want to keep the AV_QSORT()
[18:03:31 CEST] <ubitux> (and copyrights)
[18:03:45 CEST] <ubitux> otherwise i think you can take everything to reduce diffs
[18:03:58 CEST] <durandal_1707> Yes
[18:06:29 CEST] <mateo`_> I'll stop with the merges for today
[18:30:56 CEST] <BBB> I also figured out why my bench output didnt work for sub-idcts
[18:55:26 CEST] <jamrial> BBB: nice!
[18:56:57 CEST] <jamrial> it's amazing how many of these functions get a massive boost even with the simplest simd implementation
[18:57:09 CEST] <jamrial> from 14k to 2.6k with only sse2, for example
[18:58:22 CEST] <jamrial> bah, technically not simplest. the missing instructions in sse2 make it more complex to write :p
[18:58:32 CEST] <jamrial> least efficient, then
[19:41:20 CEST] <BBB> the C code is, admittedly, incredibly badly written
[19:42:33 CEST] <BBB> you can see how ssse3 is hugely helpful compared to sse2, though
[19:42:38 CEST] <BBB> which is not surprising
[19:42:41 CEST] <BBB> pmulhrsw FTW
[19:46:25 CEST] <atomnuker> yeah, but that can easily overflow
[19:49:09 CEST] <jamrial> BBB: except in 8_32 it seems. your test shows it's slower than sse2 somehow
[19:49:43 CEST] <BBB> oh I Think I know now
[19:49:52 CEST] <BBB> the subidct idea is not implemented for sse2?
[19:49:58 CEST] <BBB> it probably should be, but I didnt bother
[19:50:33 CEST] <BBB> it could shortcut the first idct_1d at least
[20:15:31 CEST] <BBB> jamrial: and that then explains why sse2 would be faster for the full one, since its already loaded in cache whereas the ssse3 one isn't
[20:32:04 CEST] <cone-567> ffmpeg 03Michael Niedermayer 07master:e879819e7b27: avfilter/vf_uspp: Check for encoding failure
[22:29:14 CEST] <bp0> michaelni, do you have concerns about the other hdcd patches?
[22:47:22 CEST] <michaelni> bp0, no but do you have testcases for the patches ?
[22:48:09 CEST] <bp0> yes, I do
[22:48:15 CEST] <michaelni> fate test(s) with small samples would also be usefull
[22:50:15 CEST] <michaelni> ideally each bugfix / feature would be covered by a fate test, one fate test could cover many features / bugfixes though
[22:51:21 CEST] <michaelni> bp0, can you post patches that add (a) fate test(s) for the patches ?
[22:51:58 CEST] <bp0> yeah, I think I could, ... I'll have to look into creating fate tests
[22:52:03 CEST] <bp0> I've not done that yet
[22:52:40 CEST] <bp0> I have an example false positive for the patch regarding that, and an example with many detectable errors
[22:52:49 CEST] <bp0> I suppose they will have to be cut down to :30 or so
[22:52:52 CEST] <bp0> right?
[22:52:58 CEST] <bp0> for copyright reasons
[22:53:43 CEST] <michaelni> smaller is better for diskspace & network bandwidth reasons 
[22:53:54 CEST] <bp0> for the patch regarding the change in call to hdcd_update_info, maybe a test with known counts?
[22:53:59 CEST] <bp0> what would be good for that
[22:55:34 CEST] <michaelni> hmm, if nothing in the sample/timestamp/metadata/... output of the filter changes then testing it is harder
[22:56:44 CEST] <bp0> oh you are saying the result of the test must be detectable in the output stream, not in the log
[22:57:44 CEST] <michaelni> the log could be tested for too in principle
[22:59:29 CEST] <bp0> I've personally tested these patches on about 520 CDs, finding about 30 HDCD-encoded among them
[22:59:53 CEST] <bp0> so I have examples of false positives, and those with errors
[23:00:04 CEST] <bp0> but I know it should be possible to make a test that can be used by others
[23:00:50 CEST] <bp0> and I will try
[23:01:14 CEST] <michaelni> ok, if you need help, ask
[23:01:19 CEST] <bp0> thank you
[00:00:00 CEST] --- Thu Jul 14 2016