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

[burek]

[00:02:15 CET] <Mavrik> Oh my, eyes bleeding.
[00:24:10 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.8:efa91285566a: avutil/softfloat: FLOAT_0 should use MIN_EXP
[00:24:11 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.8:f38beb47daa8: avutil/softfloat: Correctly set the exponent for 0.0 in av_sqrt_sf()
[00:24:12 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.8:6e4bfbe93617: avutil/softfloat: Fix typo in av_mul_sf() doxy
[00:24:13 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.8:402c4a9f81de: avutil/softfloat: Fix exponent underflow in av_mul_sf()
[00:24:14 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.8:acd203fc0d31: avutil/softfloat: Fix exponent underflow in av_div_sf()
[00:24:15 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.8:b533998d0a1d: avutil/softfloat: Add tests for exponent underflows
[00:24:16 CET] <cone-684> ffmpeg 03Ganesh Ajjanagadde 07release/2.8:476ddffccbed: avutil/common: add FFDIFFSIGN macro
[00:24:17 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.8:43ada90fc5d9: avutil/softfloat: Add test for av_cmp_sf()
[00:24:18 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.8:7ad4bf489959: avutil/softfloat: Fix overflows in shifts in av_cmp_sf() and av_gt_sf()
[00:24:19 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.8:f9998d1994bd: avutil/softfloat: Extend the av_cmp_sf() test to cover a wider range of exponents
[00:24:20 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.8:0f9c61797929: avutil/softfloat: Add test for av_gt_sf()
[00:24:21 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.8:6581e40e1a56: avutil/softfloat: Fix av_gt_sf() with large exponents try #2
[00:24:22 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.8:72be96ac5522: avutil/softfloat: Include negative numbers in cmp/gt tests
[00:24:23 CET] <cone-684> ffmpeg 03Andreas Cadhalpun 07release/2.8:e10c353ca5c3: softfloat: handle INT_MIN correctly in av_int2sf
[00:39:27 CET] <rcombs> wonder when x264 perf on aarch64 will be on par with x86_64
[00:40:28 CET] <rcombs> the A9X's Twister core apparently benches close to recent i7s in single-core performance
[00:41:05 CET] <rcombs> but it'll be a while before there're aarch64 optimizations for many of the things there are already x86_64 ones for
[01:05:04 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.8:21e42d9b0d37: avcodec/aacsbr: Use FLOAT_0
[01:05:05 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.8:8364d607ac0c: avcodec/aacsbr_fixed: Try to initialize sum[0..1] differently to fix build with VS2012
[01:05:06 CET] <cone-684> ffmpeg 03Andreas Cadhalpun 07release/2.8:ce2664f5f727: aacdec: don't return frames without data from aac_decode_er_frame
[01:05:07 CET] <cone-684> ffmpeg 03Andreas Cadhalpun 07release/2.8:46f83b059b26: aacsbr_fixed: check for envelope scalefactors overflowing
[01:19:48 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.8:c9b3451da3cf: Update Changelog
[02:48:09 CET] <cone-684> ffmpeg 03Andreas Cadhalpun 07n2.8.2:HEAD: dds: add missing newline to log messages
[04:07:50 CET] <cone-684> ffmpeg 03hSÇ 07release/2.7:99ab664ff84c: configure: loongson disable expensive optimizations in gcc O3 optimization
[04:07:51 CET] <cone-684> ffmpeg 03wm4 07release/2.7:2c8a8a114c57: rawdec: fix mjpeg probing
[04:07:52 CET] <cone-684> ffmpeg 03wm4 07release/2.7:1900d023ae7b: rawdec: fix mjpeg probing buffer size check
[04:07:53 CET] <cone-684> ffmpeg 03Emanuel Czirai 07release/2.7:5e71f4aa6ad8: libavcodec/aacdec_template: Use init_get_bits8() in aac_decode_frame()
[04:07:54 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:94541f5f7624: avcodec/dcaenc: clear bitstream end
[04:07:55 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:d165ec179e46: avcodec/svq1enc: Check dimensions
[04:07:56 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:b87fc3526f27: avcodec/flashsvenc: Correct max dimension in error message
[04:07:57 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:485372e91cc2: avformat/mux: Update sidedata in ff_write_chained()
[04:07:58 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:a8c8a2f3f4aa: ffmpeg: check avpicture_fill() return value
[04:07:59 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:ce17111ed18d: ffmpeg: Check for RAWVIDEO and do not relay only on AVFMT_RAWPICTURE
[04:08:00 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:483f5bccc129: ffmpeg: Check av_parser_change() for failure
[04:08:01 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:43b094fa03f6: ffmpeg: Use correct codec_id for av_parser_change() check
[04:08:02 CET] <cone-684> ffmpeg 03Arthur Grant 07release/2.7:717c3ebfa46f: avformat/hevc: Fix parsing errors
[04:08:03 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:679df05683e6: avformat/hevc: Check num_long_term_ref_pics_sps to avoid potentially long loops
[04:08:04 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:42fd94b5144c: avcodec/libopusenc: Fix infinite loop on flushing after 0 input
[04:08:05 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:ffcd26d25bfd: avcodec/mpeg12dec: Set dimensions in mpeg1_decode_sequence() only in absence of errors
[04:08:06 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:19a29c92db92: avcodec/truemotion1: Check for even width
[04:08:07 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:13aaefb70e78: avformat/mxg: Use memmove()
[04:08:08 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:ab91919e57d2: avformat/dump: Fix integer overflow in aspect ratio calculation
[04:08:09 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:ab3f12901171: avutil/common: Document FFABS() corner case
[04:08:10 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:03ef13889c19: avutil/common: Add FFNABS()
[04:08:11 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:1e6f641052aa: avformat/mov: Fix integer overflow in FFABS
[04:08:12 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:95db0aa276fe: swresample/swresample: Fix integer overflow in seed calculation
[04:08:13 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:dceec28eac8a: avcodec/vp3: Check init_get_bits8() for failure
[04:08:14 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:1e7ff902f2f5: avcodec/tta: Check init_get_bits8() for failure
[04:08:15 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:50e4d38ce473: avcodec/svq1dec: Check init_get_bits8() for failure
[04:08:16 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:746a65640f71: avcodec/g2meet: Fix potential overflow in tile dimensions check
[04:08:17 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:484eb2b0e3b2: avcodec/g2meet: Also clear tile dimensions on header_fail
[04:08:18 CET] <cone-684> ffmpeg 03Ganesh Ajjanagadde 07release/2.7:a30a30b59af1: avfilter/af_asyncts: use llabs for int64_t
[04:08:19 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:04ad22d77aa5: avcodec/mjpegdec: Fix decoding RGBA RCT LJPEG
[04:08:20 CET] <cone-684> ffmpeg 03Simon Thelen 07release/2.7:d1de4923305b: lavf/webvttenc: Require webvtt file to contain exactly one WebVTT stream.
[04:08:21 CET] <cone-684> ffmpeg 03Ganesh Ajjanagadde 07release/2.7:abd20c205763: avutil/log: fix zero length gnu_printf format string warning
[04:08:22 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:50f62fef19f1: avcodec/rangecoder: Check e
[04:08:23 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:54661cf0b2c9: avcodec/ffv1dec: Explicitly check read_quant_table() return value
[04:08:24 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:f10ba15d7371: avcodec/ffv1dec: Fix off by 1 error in quant_table_count check
[04:08:25 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:f43dac169efd: avcodec/x86/sbrdsp: Fix using uninitialized upper 32bit of noise
[04:08:26 CET] <cone-684> ffmpeg 03Andrey Utkin 07release/2.7:6d3f047a8592: avformat/httpauth: Add space after commas in HTTP/RTSP auth header
[04:08:27 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:f7ef26538761: avcodec/ffv1dec: Clear slice coordinates if they are invalid or slice header decoding fails for other reasons
[04:08:28 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:06c87da4104d: avcodec/ffv1dec: update progress in case of broken pointer chains
[04:08:29 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:c6cb24ffbf53: avcodec/ffv1: Initialize vlc_state on allocation
[04:08:30 CET] <cone-684> ffmpeg 03Kieran Kunhya 07release/2.7:c3ce50813540: opusdec: Don't run vector_fmul_scalar on zero length arrays
[04:08:31 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:ab6f4bc06433: avcodec/h264_slice: Disable slice threads if there are multiple access units in a packet
[04:08:32 CET] <cone-684> ffmpeg 03Tobias Rapp 07release/2.7:5ae4842122ca: avutil/file_open: avoid file handle inheritance on Windows
[04:08:33 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:edf06a056253: avcodec/mjpegdec: Check index in ljpeg_decode_yuv_scan() before using it
[04:08:34 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:32808460cc5d: avcodec/mjpegdec: Reinitialize IDCT on BPP changes
[04:08:35 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:e98f3ba22124: avcodec/ffv1dec: Check for 0 quant tables
[04:08:36 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:6acf5ff1d3c5: libavutil/channel_layout: Check strtol*() for failure
[04:08:37 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:b0b1b208f5c7: avcodec/mpeg12dec: Do not call show_bits() with invalid bits
[04:08:38 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:6ad10cbec954: avformat/xmv: factor return check out of if/else
[04:08:39 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:bcedc2b0f0e4: avformat/xmv: Discard remainder of packet on error
[04:08:40 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:327dd70690a1: avcodec/dirac_parser: Fix undefined memcpy() use
[04:08:41 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:af3a608e7e3d: avcodec/microdvddec: Check for string end in 'P' case
[04:08:42 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:169a02da1e39: avcodec/jpeg2000dec: Clip all tile coordinates
[04:08:43 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:d332aa6ec678: avcodec/hevc_ps: Check chroma_format_idc
[04:08:44 CET] <cone-684> ffmpeg 03Andreas Cadhalpun 07release/2.7:cd8bedb9fa7c: jvdec: avoid unsigned overflow in comparison
[04:08:45 CET] <cone-684> ffmpeg 03Andreas Cadhalpun 07release/2.7:132bd4bc4fb4: apng: use correct size for output buffer
[04:08:46 CET] <cone-684> ffmpeg 03Simon Thelen 07release/2.7:b9a3e0af07bc: ffmpeg: Don't try and write sdp info if none of the outputs had an rtp format.
[04:08:47 CET] <cone-684> ffmpeg 03Simon Thelen 07release/2.7:ae270314c7f4: doc/ffmpeg: Clarify that the sdp_file option requires an rtp output.
[04:08:48 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.7:4eb67f3ddcca: tests/fate/avformat: Fix fate-lavf
[06:56:01 CET] <cone-684> ffmpeg 03Matt Oliver 07master:9b9c9ef3b421: avutil/x86/bswap: Add msvc bswap instrinsics.
[06:56:02 CET] <cone-684> ffmpeg 03Matt Oliver 07master:58d32c00beef: avutil/x86/intmath: Fix intrinsic header include when using newer gcc with older icc.
[07:59:56 CET] <atomnuker> It's over
[08:00:14 CET] <atomnuker> I found a video compression codec which outdoes anything else compression wise
[08:00:32 CET] <atomnuker> turns out we even have support for it
[08:01:18 CET] <atomnuker> VP9? HEVC? Nope, TMV's the best
[08:01:58 CET] <atomnuker> and the overhead is so low you can seriously play it on a C64 or an Amiga
[08:02:14 CET] <drv> it still needs an encoder ;)
[08:12:42 CET] <atomnuker> hmm, I have an idea
[08:12:52 CET] <atomnuker> and it's just crazy enough that it might work
[08:13:26 CET] <atomnuker> libcaca can spit out ascii
[08:20:02 CET] <atomnuker> I wonder what gains you could get by strapping some entropy encoding and P-frame support to TMV
[08:20:55 CET] <atomnuker> it would probably be worth it to try intra-frame prediction, especially with small palettes
[08:22:28 CET] <atomnuker> and the format already has subtitle support built-in
[11:44:42 CET] <ubitux> mv question: in mpegvideo we apparently do motion_value >> motion_shift (at least for the export of mvs)
[11:44:59 CET] <ubitux> which in case of negative motion value has an undefined behaviour (iirc)
[11:45:23 CET] <ubitux> and actually gives different result than a motion_value / (1<<motion_shift)
[11:45:45 CET] <ubitux> example: mx:125 my:-13 scale:1 shift:62,-6 div:62,-7
[11:46:16 CET] <ubitux> so my question is: which one is the most correct (result wise)?
[11:51:46 CET] <ubitux> note: i'm looking at a way to export mvs with a subpel resolution; i'm currently adding a motion scale parameter, but we might want sth more elaborated than mv >> shift, maybe (mv+a)*b/c
[12:02:38 CET] <iive> ubitux: signed >> x ; should actually be defined as arithmetic shift. All non compliment to two system are already gone. and yes -1>>1 == -1
[12:04:36 CET] <iive> ubitux: imho, it is better to export the motion vectors as they are and provide the scaling, so the app could divide on its own.
[12:05:15 CET] <kierank> ubitux: signed shift is legal, no?
[12:06:21 CET] <ubitux> i never remember if it's the right or the left one which is undefined
[12:06:47 CET] <ubitux> but yeah i guess it's the left one
[12:07:03 CET] <ubitux> iive: right, but how do you export the scaling then?
[12:07:04 CET] <kierank> me too
[12:07:24 CET] <iive> ubitux: how do you export the motion vectors?
[12:07:38 CET] <ubitux> iive: a shift value (with a rounding flag)? 3 variables to do (mv+a)*b/c?
[12:07:58 CET] <ubitux> iive: currently with reduced precision, i'm looking at adding the scale
[12:08:08 CET] <ubitux> the question is which solution should i pick for that
[12:08:43 CET] <ubitux> motion_offset (a) and motion_scale (b/c), just a motion_shift (that won't cover everything)?
[12:09:17 CET] Action: ubitux wonders about if he can reproduce the shift with a,b,c
[12:09:21 CET] <iive> ubitux: I think we are talking for completely different things...
[12:11:16 CET] <ubitux> iive: ok. currently we are exporting mvs to the user with their source and destination coordinates pixel wise (so with loss of subpel definition)
[12:11:45 CET] <ubitux> i'm planning to actually add motion fields for the non reduced motion vector (so with its subpel definition)
[12:12:34 CET] <iive> you want to patch it over, so old format is preserved, but you get additional info?
[12:13:06 CET] <ubitux> how should i expose that information? 2 int motion_value and motion_scale? (and eventually a rounding flag to differentiate (mv+(1<<(s-1)))>>s from mv>>s) or 3 other param to calculate ((mv+a)*b/c), or something else?
[12:13:37 CET] <ubitux> iive: yes i will just add N fields (redundant but with more precision) to the AVMotionVectors public structure
[12:14:07 CET] <iive> I don't like that.
[12:14:14 CET] <ubitux> don't like what?
[12:14:22 CET] <ubitux> currently it's the following: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavutil/motion_vector.h;hb=HEAD
[12:15:35 CET] <iive> are you going to add new fields in that structure?
[12:15:41 CET] <ubitux> yes
[12:16:19 CET] <ubitux> iive: http://pastie.org/10552322
[12:16:21 CET] <ubitux> sth like this for instance
[12:18:21 CET] <iive> i don't get why yu need the a,b,c....
[12:18:35 CET] <ubitux> in case of mpeg i don't
[12:18:53 CET] <ubitux> but let's say we need rounding
[12:19:01 CET] <ubitux> or we need stuff like this in snow:
[12:19:03 CET] <ubitux>             avmv->src_x = avmv->dst_x + (bn->mx * s->mv_scale)/8;
[12:19:05 CET] <ubitux>             avmv->src_y = avmv->dst_y + (bn->my * s->mv_scale)/8;
[12:19:49 CET] <iive> mv_scale is not power of 2?
[12:20:04 CET] <ubitux> maybe
[12:20:28 CET] <iive> anyway, you can think of motion vectors are fixed point. the shift removes the bits after the point. You can just present these bits.
[12:21:52 CET] <iive> it is not better solution... just a faster one.
[12:22:42 CET] <ubitux> my issue is to find a solution generic enough to handle as many codec as possible, not a "fast" one
[12:23:01 CET] <ubitux> we are not talking about decode speed here, but debug/analysis user api
[12:23:21 CET] <iive> then you need to provide the original vectors.
[12:23:40 CET] <ubitux> no
[12:24:30 CET] <ubitux> i just need to express a scale and how to interpret it in the most common case; that is how you downscale it (rounding, div and shift)
[12:26:36 CET] <iive> so the a,b,c parameters are your attempt in universal conversion formula
[12:30:20 CET] <ubitux> it's just a random guess, but i don't like it wrt to how you will handle "shift mv codecs" with such parameters
[12:30:29 CET] <ubitux> that's why i'm asking for suggestions
[12:30:29 CET] <wm4> always so nice if employee 1 from company A "reviews" and acks the corporate code patch of employee 2 of company A
[12:30:58 CET] <ubitux> haha
[12:31:27 CET] <wm4> (without ever actually reviewing it, definitely not in public at least)
[12:39:25 CET] <kierank> repacking rtmp to udp mpegts
[12:39:26 CET] <kierank> wow
[12:49:02 CET] <Compn> kierank : it works ? 
[12:49:11 CET] <kierank> it is a terrible idea
[12:49:19 CET] <kierank> it will never work properly
[13:28:02 CET] <Compn> oh, :P
[13:29:15 CET] <Compn> i know a few devs were doing rtmp > mpegts (but not udp) for android/iphones
[13:29:36 CET] <Compn> to do hulu without flashplugin
[13:30:07 CET] <Compn> more probably rtmp>mp4 though
[13:53:56 CET] <BtbN> Compn, browser can play mpeg-ts now, too
[13:54:08 CET] <BtbN> Someone made a JavaScript transmuxer...
[13:54:25 CET] <BtbN> So hls actualy works everywhere now
[14:26:37 CET] <Compn> its weird how the web browser now plays more videos than a media player
[14:26:49 CET] <Compn> i mean, statistically. youtube netflix hulu etc
[14:27:33 CET] <BtbN> And it's braindead stupid how it does it...
[14:27:47 CET] <BtbN> instead of just supporting mpeg-ts(Which Chrome easily could, it contains a full ffmpeg)...
[14:28:06 CET] <Compn> of course its braindead, its chrome.
[14:28:23 CET] <BtbN> Instead they artificialy limit the format to mp4
[14:28:43 CET] <BtbN> And then someone uses emscripten to compile ffmpeg to asm.js, which then transmuxes mpeg-ts to mp4, just to feed it to another ffmpeg running in chrome
[14:29:28 CET] <Compn> j-b should work on porting the vlc features and interface into web browsers. will media players still be a thing in 5 years?
[14:29:57 CET] <BtbN> Only if they support the DRM blob of the digital right holder you want to play a video from.
[14:30:46 CET] <Compn> not talking about web plugins either, i mean directly in the browser code..
[14:31:35 CET] <Compn> BtbN : i wonder if someone made a patch to unlock the mpegts ffmpeg in chromium, if chrome would follow?
[14:31:58 CET] <BtbN> There was a feature request about that
[14:32:00 CET] <Compn> does chromium ship ffmpeg? a few years ago i remember they didnt, but i havent checked lately.
[14:32:02 CET] <BtbN> it was closed as wontfix
[14:32:23 CET] <BtbN> iirc they have their own fork of libav* they use for their media stuff
[14:33:11 CET] <BtbN> The Chrome/Chromium engine general does support mpegts/hls playback
[14:33:17 CET] <BtbN> The Android-Version supports it
[14:33:23 CET] <BtbN> But on Desktop-Builds it's disabled
[14:33:31 CET] <BtbN> So it only supports mp4/DASH
[14:33:56 CET] <wbs> BtbN: it doesn't run through the chrome engine on android
[14:33:58 CET] <nevcairiel> does it? isnt that just javascript?
[14:34:09 CET] <wbs> BtbN: it just passes all of that to the system media player stack
[14:34:16 CET] <wbs> BtbN: for hls that is
[14:34:34 CET] <BtbN> hm
[14:35:06 CET] <BtbN> nevcairiel, well, DASH is a lot of JavaScript, but it doesn't have to transmux the mp4 chunks
[14:56:29 CET] <ubitux> so, for the mvs, i think i'm going for (mv * a) >> s
[14:56:32 CET] <ubitux> any objection?
[14:56:50 CET] <ubitux> so motion_scale (a) and motion_shift (s)
[14:59:05 CET] <ubitux> unfortunately it won't "work" with the div in snow :(
[14:59:13 CET] <ubitux> michaelni: opinion?
[15:03:50 CET] <TD-Linux> BtbN, chrome (and firefox) don't support TS (and therefore HLS) due to IPR issues
[15:04:22 CET] <BtbN> So there are patents just on the container itself?
[15:04:29 CET] <kierank> yes
[15:04:29 CET] <michaelni> ubitux, not sure i understand the question
[15:04:31 CET] <TD-Linux> of course, you can patent everything
[15:04:54 CET] <BtbN> Would have expected mp4/mov to be much worse in that regard
[15:04:56 CET] <wm4> IPR issues?
[15:05:10 CET] <TD-Linux> wm4, patent licenses
[15:05:13 CET] <ubitux> michaelni: http://ffmpeg.org/pipermail/ffmpeg-devel/2015-November/183145.html
[15:05:22 CET] <nevcairiel> IPR=intellectual property rights
[15:05:25 CET] <wm4> what patents are there for .ts?
[15:05:26 CET] <ubitux> michaelni: in snow i use motion_shift=3 (instead of a /8)
[15:05:48 CET] <ubitux> michaelni: which will lead to a change in how the mv are interpreted
[15:06:29 CET] <ubitux> should i simply add a motion_div so we have a motion_shift=0 motion_div=8 and motion_shift=x motion_div=1 in mpeg*?
[15:06:45 CET] <TD-Linux> wm4, see MPEG-LA's "MPEG-2 Systems"
[15:06:46 CET] <ubitux> (motion_shift=0 motion_div=8 for snow)
[15:06:58 CET] <TD-Linux> (non-comprehensive)
[15:09:38 CET] <michaelni> ubitux, i think the /8 is just because the existing side data syntax doesnt support subpel, if one adds subpe support theres no divide
[15:10:09 CET] <TD-Linux> BtbN, also mp4 is actually in a much better position. there's a reason DASH uses mp4 :)
[15:10:20 CET] <ubitux> michaelni: but what is the proper calculation of the motion?
[15:10:25 CET] <ubitux> a /8 or a >>3?
[15:10:43 CET] <michaelni> you have motion vectors in some higher than 1pixel precission
[15:10:46 CET] <ubitux> (given that with a neg motion it won't lead to the same thing)
[15:11:44 CET] <michaelni> if you have a mtion vector of (-0.25,-0.75) pixels then thats just what you have, i dont see where theres any shift, divide or anything
[15:11:55 CET] <michaelni> not in the syntax of the export
[15:12:19 CET] <michaelni> maybe in the interpretation if you want to draw inaccurate arrows
[15:12:57 CET] <michaelni> but a -0.25 is a -0.25 its not a 1 nor a 0
[15:14:28 CET] <ubitux> so both downscale (be it shift or div) are innacurate anyway since the code never really does work at pixel level?
[15:14:39 CET] <ubitux> so it's not a problem?
[15:15:28 CET] <michaelni> i think so yes, IIUC
[15:16:08 CET] <ubitux> cool ok
[15:16:13 CET] <ubitux> so i guess the patch is ok :]
[15:22:39 CET] <BtbN> TD-Linux, using a non-streamable format for video streaming still is stupid.
[15:23:02 CET] <kierank> ^that
[15:24:07 CET] <nevcairiel> yeah all the hacks mp4 had to go through to become streamable...
[15:24:12 CET] <nevcairiel> someone really wanted to use mp4
[15:25:52 CET] <TD-Linux> BtbN, indeed it is awful.
[15:26:02 CET] <TD-Linux> if you think that's bad, go look at MMT
[15:26:45 CET] <TD-Linux> indexless matroska or ogg would have made more sense, but neither of those are MPEG standards, so they only had two choices...
[15:27:33 CET] <kierank> nevcairiel: clueless web people
[15:27:43 CET] <kierank> mmt...
[15:28:09 CET] <TD-Linux> kierank, those "clueless web people" being MPEG and including broadcasters...
[15:28:13 CET] <TD-Linux> (not arguing the clueless part)
[15:28:21 CET] <wm4> trollol
[15:28:22 CET] <kierank> well using mp4 for streaming = cluesless
[15:28:34 CET] <kierank> yes there are web people equally clueless in broadcasters
[15:30:19 CET] <TD-Linux> you can actually stream webm directly to firefox or chrome without any JS or DASH or the like. though I know of about 2 people who have ever done this
[15:31:12 CET] <TD-Linux> live stream that is
[15:32:01 CET] <nevcairiel> i tried to do th at once, and it workd ok'ish, heck even mkv with avc worked to some degree in chrome, but usually I was looking for a solution that covers more platforms
[15:32:16 CET] <ubitux> note: would be nice to be able to export mvs from more codecs btw
[15:34:17 CET] <wm4> what's so great about mvs?
[15:35:33 CET] <ubitux> cheap (both in speed and quality) global motion estimation
[15:35:40 CET] <ubitux> (if you're doing analysis)
[15:35:42 CET] <ubitux> and debug
[15:35:48 CET] <ubitux> if you're... curious about codecs
[15:35:58 CET] <ubitux> cf codecview
[15:36:02 CET] <TD-Linux> you should try a real stream analyzer for the latter case :)
[15:36:06 CET] <wbs> TD-Linux: I've done that webm streaming as well, and the same thing for fragmented mp4 streaming also
[15:36:19 CET] <wm4> for analysis, a dedicated motion estimation thing would probably be better
[15:37:38 CET] <TD-Linux> yeah codec MVs are going to be RDO'd. it is kind of a clever hack though, you could also use them to seed a refinement search
[15:37:46 CET] <ubitux> wm4: except it's very expensive and not appropriate for realtime
[15:38:06 CET] <TD-Linux> you can totally do a motion search in realtime. how do you think video conferencing works?
[15:38:35 CET] <ubitux> on phones while doing other stuff you think you can do it?
[15:38:38 CET] <nevcairiel> there is a whole bunch of things that do motion search in realtime, either for realtime compression or interpolation
[15:38:52 CET] <TD-Linux> ubitux, probably, phones usually use software encoders for video chat
[15:39:28 CET] <ubitux> what algorithm would you suggest?
[15:40:25 CET] <ubitux> and it's going to give similar results to what an encoder can do, then it's still interesting to just not do that calculation and reuse it
[15:40:32 CET] <ubitux> +if
[15:40:35 CET] <wm4> uh not sure, but it'd had to be something that actually detects motion (and not good compression matches)
[15:40:54 CET] <wm4> avisynth and vapoursynth have special filters for this stuff (what was it called again)
[15:41:13 CET] <nevcairiel> avisynth has mvtools
[15:42:48 CET] <wm4> right
[15:42:52 CET] <wm4> and vapoursynth has a port
[15:43:10 CET] <wm4> and why is ffmpeg-devel putting my mails into the moderattion queue
[15:43:18 CET] <nevcairiel> usually not signed up
[15:43:26 CET] <nevcairiel> wrong sender mail?
[15:44:01 CET] <wm4> To: nfxjfg at gmail.com
[15:44:11 CET] <wm4> seems like google is changing my sender mail now
[15:44:30 CET] <nevcairiel> that can only be a good thing, the googlemail thing was broken as f' =p
[15:45:02 CET] <wm4> it used to do it the other way around (change gmail to googlemail, though not when sending mails)
[15:47:26 CET] <Compn> wm4 : do you need me to add any addy into the "always accept" mod list ?
[15:47:46 CET] <wm4> that would be good
[15:58:28 CET] <Compn> yeah i only see nfxjfg at googlemail.com in the membership list :P
[15:59:22 CET] <Compn> added @gmail to always accept... should be ok now
[15:59:32 CET] <wm4> thanks
[16:01:08 CET] <Compn> thats just for -devel though. probably must be done for all lists...
[16:01:14 CET] <Compn> individually
[16:26:52 CET] <kierank> wm4: looool
[16:26:59 CET] <kierank> "165.255.249.185"
[16:27:01 CET] <kierank> whoops
[16:27:06 CET] <kierank> Btw, this cast works (even it´s not allowed) ...
[16:28:24 CET] <nevcairiel> corporate people should not be trusted to review other coporate persons code =p
[16:33:09 CET] <wm4> also, this uses internal libavcodec symbols from libavfilter
[16:33:13 CET] <wm4> this shouldn't even link
[16:33:21 CET] <nevcairiel> static binary probably
[16:33:22 CET] <wm4> unless it's built as static lib
[16:34:15 CET] <nevcairiel> the init session function you mean? that one is rather trivial and should just be re-implemented really
[16:39:30 CET] <ubitux> hahaha the cast wtf
[16:41:11 CET] <nevcairiel> he got lucky because the function he called only used it as a log context and nothing else
[17:02:04 CET] <roxlu> Hey, does someone maybe knows a bit about the Windows Media Transform for AAC encoding? I was trying to watch a AAC/AVC stream, using MPEG-DASH transport but the video couldn't be played with Chromium. I saw that the issue occured wen the ffmpeg audio decoder in Chromium notices a configuration change. This change is triggered because the IMFTransform uses the wrong number of output channels. I'm wondering if someone knows more
[17:02:04 CET] <roxlu>  about AAC encoding on windows and maybe what could cause this issue?
[19:18:07 CET] <kierank> to think that qsv patch was going to get the famous "applied"
[19:34:44 CET] <Fyr> guys, is anyone here interested in fixing bugs?
[19:37:44 CET] <kierank> no
[19:43:48 CET] <Fyr> yes, it looks like.
[19:44:23 CET] <durandal_1707> what bug?
[19:44:30 CET] <Fyr> any bug
[19:44:43 CET] <Fyr> look at the ffmpeg tracker
[19:45:04 CET] Action: kierank walks to the rack and looks at the tracker
[19:45:11 CET] <kierank> yes it's still there
[19:45:14 CET] <kierank> your point is what?
[19:45:28 CET] <durandal_1707> there are many be more specific
[19:45:35 CET] <Fyr> 1170 OPEN BUGS!
[19:45:37 CET] <J_Darnley> I'm only interested in fixing bugs that affect me.
[19:45:43 CET] <Fyr> some o them even four years old.
[19:45:58 CET] <kierank> Fyr: where are your patches
[19:46:21 CET] <durandal_1707> hard or nobody paid
[19:46:27 CET] <Fyr> KKKKKKKKKKKKKKKKKKK
[19:46:29 CET] <J_Darnley> Oh no!  Someone hasn't added Feature X that was requested 4 years ago.
[19:46:30 CET] <Fyr> been there
[19:46:33 CET] <Fyr> done that
[19:48:23 CET] <J_Darnley> 379 feature requests
[19:48:27 CET] <durandal_1707> what bug, maybe I will fix it..
[19:48:46 CET] <J_Darnley> 747 defects
[19:49:07 CET] <J_Darnley> 5 tasks
[19:49:16 CET] <durandal_1707> and violators
[19:49:17 CET] <J_Darnley> 36 license violations
[19:49:29 CET] <J_Darnley> 0 art
[19:49:43 CET] <J_Darnley> 2 sponsor requests
[19:49:51 CET] <durandal_1707> -6 bounty
[19:50:05 CET] <kierank> there I fixed a bug
[19:50:08 CET] <kierank> (well Timothy_Gu did)
[19:50:23 CET] Action: J_Darnley applauds
[19:50:41 CET] <Fyr> 1169 are to go
[19:50:52 CET] <J_Darnley> *746 to go
[19:53:44 CET] <kierank> durandal_1707: what should I fuzz
[19:53:51 CET] <kierank> vp9 got boring and slow :(
[19:59:17 CET] <jamrial> hevc?
[20:00:38 CET] <atomnuker> opus?
[20:03:31 CET] <durandal_1707> kierank: real and wma codecs and demuxers
[20:07:16 CET] Action: J_Darnley applauds
[20:09:40 CET] <JEEB> Fyr: if you were the person earlier complaining about swscale sucking, I must say zimg-using zscale filter is sweet as far as the output goes :P
[20:10:11 CET] <philipl> We all have to do our part to close bugs that others have fixed :-)
[20:10:19 CET] <Fyr> JEEB, you're wrong.
[20:10:36 CET] <JEEB> I always am
[20:19:40 CET] <jamrial> kierank: if you want to fuzz audio, aac, dca, flac, mp3, opus and ac3 are the best choices
[20:20:24 CET] <jamrial> opus mainly. it's the newest decoder so probably tested the least
[20:21:11 CET] <jamrial> or dca if you enable the experimental hd-ma extension
[20:33:30 CET] <kierank> Might do opus again yes
[20:33:42 CET] <kierank> Did mp2 had nothing
[20:42:45 CET] <BBB> kierank: did you re-try vp9?
[20:42:59 CET] <BBB> or still turd-slow?
[20:48:14 CET] <kierank> Guess I could try another sample
[20:57:09 CET] <BBB> sorry about the speed
[20:57:13 CET] <BBB> I wonder why it takes so long
[20:57:57 CET] <BBB> I think I suggested before to put artificially small resolution limits in the bitstream header checking
[20:58:05 CET] <BBB> that may speed it up somewhat, but I dont know :/
[21:53:03 CET] <Timothy_Gu> kierank: :) forgot to close the ticket
[22:19:33 CET] <wm4> meh, qsv in libavutil
[22:30:48 CET] <nevcairiel> nothx
[22:32:37 CET] <nevcairiel> Don't want these people building public API now that will plague us for decades
[22:33:26 CET] <nevcairiel> Because they'll be gone after their company moves on
[22:34:03 CET] <J_Darnley> make them build libqsv
[22:38:48 CET] <nevcairiel> The only reason this session code is as complex as it is, is because Intel is incapable of providing it in their dispatcher library on Linux (while they do on Windows) and using Lucas variant of the dispatcher which adds the Linux Logic is apparently not acceptable
[22:38:56 CET] <nevcairiel> So hack around it in ffmpeg
[22:45:30 CET] <wm4> that's all a load of shit
[22:45:42 CET] <wm4> I wonder why ffmpeg accepts such submissions at all
[22:45:57 CET] <wm4> I mean, if intel doesn't want to use this on linux, fine
[22:46:05 CET] <wm4> let them maintain their own transcoder
[22:46:31 CET] <wm4> if nvidia with their nvenc API make the license so that nobody can use it... fine, why should ffmpeg care about this API
[22:46:45 CET] <cone-318> ffmpeg 03Will Kelleher 07master:b1a32429ef6c: hevc: Fix a53 caption extraction
[22:46:45 CET] <cone-318> ffmpeg 03KO Myung-Hun 07master:6248f23859eb: os2threads: Add pthread_once()
[22:47:59 CET] <nevcairiel> the license thing is also quite annoying, but apparently j-b talked them into changing it in the future
[23:49:14 CET] <cone-318> ffmpeg 03Michael Niedermayer 07master:0106a20aeae8: avformat/mux: Rename compute_pkt_fields2(), the name is absolutely terrible
[23:49:15 CET] <cone-318> ffmpeg 03Michael Niedermayer 07master:5324109dd7e1: avformat/segafilm: Fix current_sample after seeking and avio_seek return type
[23:57:55 CET] <nevcairiel> now that we're planning to remove it, it gets renamed? :p
[23:58:00 CET] <nevcairiel> someone wants to make my work harder
[00:00:00 CET] --- Fri Nov 13 2015