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

Thu Nov 12 02:05:02 CET 2015

[00:06:22 CET] <cone-726> ffmpeg 03Bryan Huh 07master:85e3c31fd54c: avformat/mov: Add option to ignore chapters during parsing
[00:18:38 CET] <cone-726> ffmpeg 03Matt Oliver 07master:91053990602d: avutil/x86/intmath: Disable use of tzcnt on older intel compilers.
[00:40:47 CET] <cone-726> ffmpeg 03Andreas Cadhalpun 07master:f621749d1181: dvdsubdec: validate offset2 similar to offset1
[00:44:47 CET] <cone-726> ffmpeg 03Michael Niedermayer 07master:4819446eae45: avcodec/webvttdec: Fix uninitialized use of variable "again"
[01:01:08 CET] <ubitux> ffs git send email
[01:01:10 CET] <ubitux> die in hell
[01:01:20 CET] <rcombs> what'd you do
[01:01:27 CET] <ubitux> i run "git send-email"
[01:01:31 CET] <ubitux> and it doesn't work
[01:01:32 CET] <ubitux> so i'm angry
[01:01:35 CET] <ubitux> [Net::SMTP::SSL] Connection closed at /usr/lib/git-core/git-send-email line 1351.
[01:01:37 CET] <ubitux> :(
[01:01:46 CET] <rcombs> 10/10 error message
[01:04:47 CET] <iive> ubitux: --smtp-debug=1
[01:05:22 CET] <ubitux> Net::SMTP::SSL: Net::Cmd::datasend(): unexpected EOF on command channel:  at /usr/lib/git-core/git-send-email line 1351.
[01:05:24 CET] <ubitux> lol
[01:05:39 CET] <ubitux> but thanks :)
[01:06:06 CET] <ubitux> i like this message though:
[01:06:11 CET] <ubitux> > fatal: 'send-email' appears to be a git command, but we were not
[01:06:22 CET] <ubitux> > able to execute it. Maybe git-send-email is broken?
[01:06:28 CET] <ubitux> oh yeah maybe it's complete shit indeed
[01:08:08 CET] <iive> ubitux: does it succeed with --dry-run ?
[01:10:07 CET] <iive> gah, it's perl
[01:10:32 CET] <ubitux> yes with --dry-run it works
[01:10:36 CET] <rcombs> write-only language
[01:11:32 CET] <jamrial> ubitux: how long is the email?
[01:11:52 CET] <jamrial> i think i got that error when i tried to send a pack that weighed several kb
[01:11:54 CET] <ubitux> 856 line
[01:13:19 CET] <jamrial> try cutting it in half and sending it to yourself, see if it works
[01:14:35 CET] <ubitux> how can 28K be too big? oO
[01:14:42 CET] <ubitux> but sure ok..
[01:15:43 CET] <ubitux> jamrial: doesn't help
[01:15:50 CET] <ubitux> well, maybe it's just my mailer configuration
[01:16:41 CET] <ubitux> but i get an auth succeed
[01:18:00 CET] <iive> ubitux: your git version seems to be different that what I have...
[01:18:48 CET] <ubitux> jamrial: wait no
[01:18:50 CET] <ubitux> you're right
[01:18:52 CET] <ubitux> ... FFS
[01:18:58 CET] <ubitux> 28K is too big wth
[01:21:55 CET] <ubitux> alright, let's patch that perl
[01:27:00 CET] <ubitux> jamrial: http://permalink.gmane.org/gmane.comp.version-control.git/274569
[01:27:06 CET] <ubitux> the patch at the end seems to do the trick
[01:31:52 CET] <iive> huh... google anti-spam protection?
[01:32:03 CET] <iive> looks too easy to bypass.
[01:33:55 CET] <cone-726> ffmpeg 03Michael Niedermayer 07master:1b539fbfe36c: avfilter/avf_showcqt: Fix uninitialized return code
[01:37:21 CET] <ubitux> unrelated to google, it's my own smtpd
[01:38:41 CET] <wm4> ubitux: what is this watcher_thread for?
[01:44:12 CET] <ubitux> wm4: read the first paragraph after the list
[01:45:16 CET] <ubitux> each decoder spawn a watcher to the frame queue it's feeling
[01:45:30 CET] <ubitux> so the watcher will just watch the queue and call the user callback
[01:45:48 CET] <ubitux> so that it's not blocking for the user to filter or render the frame
[01:45:55 CET] <ubitux> the demuxing and decoding can continue
[01:46:07 CET] <ubitux> without involving any threading mechanism for the user
[01:46:33 CET] <wm4> I don't know, seems a rather roundabout way of doing what dshow/gstreamer style filters would do much more straightforward
[01:48:06 CET] <ubitux> well, using dshow/gstreamer is not going to solve any issue in ffmpeg
[01:56:18 CET] <RiCON> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=4819446 uh, cool, created a security issue
[01:56:41 CET] <RiCON> i thought it was like python and "int a, b, c = 0" meant they're all initialized to 0
[01:57:06 CET] <rcombs> nope
[01:58:34 CET] <RiCON> so "i" doesn't need it because it's assigned right after, and "again" may not
[01:59:15 CET] <wm4> you can't spell fuck without C
[02:19:42 CET] <cone-726> ffmpeg 03Michael Niedermayer 07master:8f3a9603538b: ffmpeg_filter: remove redundant null ptr check
[02:46:55 CET] <cone-726> ffmpeg 03Michael Niedermayer 07release/2.8:aa34146e41b7: avcodec/h264_slice: Disable slice threads if there are multiple access units in a packet
[02:46:56 CET] <cone-726> ffmpeg 03Tobias Rapp 07release/2.8:c6c801d993bb: avutil/file_open: avoid file handle inheritance on Windows
[02:46:57 CET] <cone-726> ffmpeg 03Michael Niedermayer 07release/2.8:fdb884263974: avcodec/mjpegdec: Check index in ljpeg_decode_yuv_scan() before using it
[02:46:58 CET] <cone-726> ffmpeg 03Michael Niedermayer 07release/2.8:4567cba0b8b8: avcodec/mjpegdec: Reinitialize IDCT on BPP changes
[02:46:59 CET] <cone-726> ffmpeg 03Michael Niedermayer 07release/2.8:a6ae88bb25d6: avcodec/ffv1dec: Check for 0 quant tables
[02:47:00 CET] <cone-726> ffmpeg 03Michael Niedermayer 07release/2.8:ff30907205fc: avcodec/hevc_ps: Check chroma_format_idc
[02:47:01 CET] <cone-726> ffmpeg 03Michael Niedermayer 07release/2.8:c7174d5204bf: avformat/mpegts: Only start probing data streams within probe_packets
[02:47:02 CET] <cone-726> ffmpeg 03Michael Niedermayer 07release/2.8:129003762600: libavutil/channel_layout: Check strtol*() for failure
[02:47:03 CET] <cone-726> ffmpeg 03Michael Niedermayer 07release/2.8:a7bbb7fb884a: avcodec/faxcompr: Add missing runs check in decode_uncompressed()
[02:47:04 CET] <cone-726> ffmpeg 03Michael Niedermayer 07release/2.8:6e085f9a324e: avcodec/mpeg12dec: Do not call show_bits() with invalid bits
[02:47:05 CET] <cone-726> ffmpeg 03Michael Niedermayer 07release/2.8:2817eb514cb7: avformat/xmv: factor return check out of if/else
[02:47:06 CET] <cone-726> ffmpeg 03Michael Niedermayer 07release/2.8:b93a8bd838dd: avformat/xmv: Discard remainder of packet on error
[02:47:06 CET] <cone-726> ffmpeg 03Michael Niedermayer 07release/2.8:2de2959305c5: avcodec/dirac_parser: Fix undefined memcpy() use
[02:47:08 CET] <cone-726> ffmpeg 03Michael Niedermayer 07release/2.8:11b4822ddb3e: avcodec/microdvddec: Check for string end in 'P' case
[02:47:09 CET] <cone-726> ffmpeg 03Michael Niedermayer 07release/2.8:56419053bcae: avcodec/jpeg2000dec: Clip all tile coordinates
[02:47:10 CET] <cone-726> ffmpeg 03Andreas Cadhalpun 07release/2.8:e217224456af: jvdec: avoid unsigned overflow in comparison
[02:47:11 CET] <cone-726> ffmpeg 03Andreas Cadhalpun 07release/2.8:c0cd8747ef14: apng: use correct size for output buffer
[02:47:12 CET] <cone-726> ffmpeg 03Simon Thelen 07release/2.8:dac3598563ad: ffmpeg: Don't try and write sdp info if none of the outputs had an rtp format.
[02:47:13 CET] <cone-726> ffmpeg 03Simon Thelen 07release/2.8:e5a2f5e74d09: doc/ffmpeg: Clarify that the sdp_file option requires an rtp output.
[02:47:14 CET] <cone-726> ffmpeg 03Michael Niedermayer 07release/2.8:84f8157662f1: tests/fate/avformat: Fix fate-lavf
[02:47:15 CET] <cone-726> ffmpeg 03Michael Niedermayer 07release/2.8:9a6d58107650: avformat/mxfenc: Only store user comment related tags when needed
[02:48:13 CET] <wm4> michaelni_: can 2.8 also have rcomb's mp4 sidx patch? (not sure how risky)
[03:19:40 CET] <cone-726> ffmpeg 03Michael Niedermayer 07release/2.8:8d634be4cea1: update versions for 2.8.2
[03:19:41 CET] <cone-726> ffmpeg 03Rodger Combs 07release/2.8:edf5e88eac83: lavf/mov: add support for sidx fragment indexes
[03:20:26 CET] <rcombs> apparently yes
[08:32:18 CET] <nevcairiel> ubitux: first thought: way too complex, what happend to 3 simple functions to call
[08:32:19 CET] <nevcairiel> :D
[08:33:21 CET] <nevcairiel> the proposal seems to be focused on solving quite a different issue than most of us
[08:35:09 CET] <nevcairiel> all we wanted was m:n support, we dont need 20 new threads for that .)
[09:32:27 CET] <cone-518> ffmpeg 03Paul B Mahol 07master:2905c5120448: avformat/rsd: XMA2 is actually stored, not XMA1
[13:02:15 CET] <nevcairiel> so.. simd experts, I want to convert uvuvuvuv -> uuuu and vvvv, whats the best way to do that? I tried using and's & shifts to separate them, and then packing, but wondering if there is something better, sse2 compatible :)
[13:05:32 CET] <iive> nevcairiel: it looks exactly like unpacking
[13:05:53 CET] <nevcairiel> unpacking is the other way around
[13:05:58 CET] <nevcairiel> it interleaves
[13:06:01 CET] <nevcairiel> i want to deinterleave
[13:06:02 CET] <nevcairiel> :D
[13:06:30 CET] <iive> ok, then it looks exactly like packing... are these 8 bit?
[13:06:39 CET] <iive> aka bytes
[13:06:44 CET] <nevcairiel> unfortunately packing is not the opposite of unpacking
[13:06:48 CET] <nevcairiel> not exactly, anyway
[13:07:13 CET] <nevcairiel> and it it can be both 8 or 16 bit values
[13:08:54 CET] <nevcairiel> so what I do now is copy the input into two regs, so I take uvuv and make it 0u0u and 0v0v, do that twice, which i can then pack
[13:09:19 CET] <nevcairiel> but that seems somewhat inefficient
[13:10:31 CET] <atomnuker> kierank deals with exactly these things
[13:10:47 CET] <iive> just a moment, I've seen code that already does it. afair it as pack unpack 
[13:11:38 CET] <ubitux> nevcairiel: yes, the goal kind of drifted because i wanted to leverage the need for the user to do thread by himself
[13:11:51 CET] <iive> nevcairiel: btw, do you want the end result to be uuuuvvvv, or you want it uuuuuuuu and vvvvvvvv in separate registers?
[13:11:57 CET] <nevcairiel> iive: separate
[13:12:10 CET] <nevcairiel> which is probably easier anyway
[13:12:13 CET] <ubitux> nevcairiel: in arm you have an instruction to read directly like this, in intel i don't remember :(
[13:12:39 CET] <nevcairiel> in this particular use-case, I want to deinterleave nv12 to yuv420
[13:12:40 CET] <iive> yes, you just need double the input :)
[13:12:53 CET] <nevcairiel> so split uvuvuvuv into uuuu vvvv
[13:13:27 CET] <ubitux> maybe just a pshufb but well
[13:13:35 CET] <nevcairiel> thats not sse2
[13:13:35 CET] <nevcairiel> :)
[13:13:43 CET] <nevcairiel> i thought about that
[13:13:59 CET] <nevcairiel> but its probably not that much more efficient that its worth adding a sse3/4? version
[13:15:16 CET] <ubitux> nevcairiel: look at SPLATB_MIX in vp9lpf.asm
[13:16:05 CET] <nevcairiel> swscale seems to do what I did
[13:16:17 CET] <nevcairiel> pand/psrlw two distinct regs, and then packuswb them
[13:17:18 CET] <nevcairiel> guess i'll just stick to that
[13:18:59 CET] <nevcairiel> hm actually, the code i'm using here is sse4, maybe I should just use pshufb
[13:41:59 CET] <iive> nevcairiel: actually doing unpack 3 times produces the result you want. 
[13:44:02 CET] <BBB> nevcairiel: I believe and and pack is easiest, yes
[13:44:09 CET] <BBB> thats what most trivial simd usually does
[13:44:18 CET] <BBB> and shift+pack for the v
[13:44:28 CET] <nevcairiel> guess my naive solution was right then!
[13:45:48 CET] <BBB> if you want to do both in the same function, pshufb 02468ace13579bdf is better
[13:45:55 CET] <BBB> that gives you (as iive said) uuuuvvvv
[13:46:14 CET] <BBB> and then SBUTTERFLY (punpcklbw+hbw) on two to get ux16+vx16
[13:46:22 CET] <BBB> or I guess punpcklqdq/hqdq
[13:46:53 CET] <BBB> because the pand/psrlw require two instructions (one per component) for the deinterleaving, and pshufb does it in one combined
[13:47:29 CET] <nevcairiel> pshufb coefficients look like magic
[13:47:37 CET] <iive> because they are :)
[13:48:00 CET] <iive> btw, wasn't shuffle a bit slow on early cpu's?
[13:48:15 CET] <BBB> atom
[13:48:28 CET] <BBB> atom pshufb is like the matrix
[13:48:37 CET] <BBB> but on new cpus pshufb is ok
[13:48:54 CET] <iive> like the matrix?
[13:48:59 CET] <BBB> the bullet-dodging scene
[13:49:09 CET] <BBB> slow motion :D
[13:51:10 CET] <BBB> https://www.youtube.com/watch?v=xZ0OUq_kDh8
[13:55:16 CET] <iive> oh... I thought that it is not the matrix that is slow, but that they are fast.
[13:55:39 CET] <nevcairiel> it is, but the movie shows it differently, otherwise it would be boring
[14:20:23 CET] <kierank> has anyone tried a xeon d?
[14:20:29 CET] <kierank> Gramner perhaps?
[14:41:59 CET] <cone-684> ffmpeg 03Anton Khirnov 07master:8de1ee9f725a: lavf: deprecate compute_pkt_fields2
[14:42:00 CET] <cone-684> ffmpeg 03Hendrik Leppkes 07master:c03ffe1712e6: avformat/utils: re-factor freeing AVStreams
[14:42:01 CET] <cone-684> ffmpeg 03Hendrik Leppkes 07master:611c22140a54: Merge commit '8de1ee9f725aa3c550f425bd3120bcd95d5b2ea8'
[14:42:53 CET] <cone-684> ffmpeg 03Anton Khirnov 07master:79f5347a9833: avcodec: fix doxy placement
[14:42:54 CET] <cone-684> ffmpeg 03Hendrik Leppkes 07master:b33d58c31f21: Merge commit '79f5347a983342e2711ca8ba19ec3d8d151183f0'
[14:48:53 CET] <cone-684> ffmpeg 03Nicolas George 07master:48ff6683ba5d: lavfi: add a frame_rate field to AVFilterLink.
[14:48:53 CET] <cone-684> ffmpeg 03Hendrik Leppkes 07master:0b73d0ff0df7: Merge commit '48ff6683ba5d40b629428673b1028e8ec542a9fa'
[14:49:33 CET] <cone-684> ffmpeg 03Nicolas George 07master:61fb67dcb2e7: buffersrc: accept the frame rate as argument.
[14:49:34 CET] <cone-684> ffmpeg 03Hendrik Leppkes 07master:6375ba827a6d: Merge commit '61fb67dcb2e71a268c422fc19d366040e59fb337'
[14:50:26 CET] <cone-684> ffmpeg 03Nicolas George 07master:1062880d69a4: vf_fps: set frame_rate.
[14:50:27 CET] <cone-684> ffmpeg 03Hendrik Leppkes 07master:4e8f1c6fb002: Merge commit '1062880d69a4fdc8d8929dd5c22bb447182f1c41'
[14:51:55 CET] <cone-684> ffmpeg 03Michael Niedermayer 07master:9df477e03ef7: yadif: update frame rate
[14:51:56 CET] <cone-684> ffmpeg 03Hendrik Leppkes 07master:cb987128666a: Merge commit '9df477e03ef74068f3de130adc4dd34349a16ef2'
[14:53:29 CET] <cone-684> ffmpeg 03Stefano Sabatini 07master:5e91a5c5cf1d: testsrc: set output framerate
[14:53:30 CET] <cone-684> ffmpeg 03Hendrik Leppkes 07master:3ce3973e5c26: Merge commit '5e91a5c5cf1db88f254b4c358eb1b06ff6ca274f'
[14:55:46 CET] <wm4> so I'm calling swr_set_compensation(avctx, 5, 1029); and swr_convert(..., ..., 1052, ..., 1024), and I'm getting back 1028 samples (where it should be 1029)
[14:55:51 CET] <wm4> michaelni_: is that correct?
[14:58:14 CET] <cone-684> ffmpeg 03Stefano Sabatini 07master:018bdaed37d2: setpts: add FRAME_RATE constant
[14:58:15 CET] <cone-684> ffmpeg 03Hendrik Leppkes 07master:ef636aacf54e: Merge commit '018bdaed37d2f1735dbecfc58309a1a164abadd5'
[14:58:32 CET] <cone-684> ffmpeg 03Michael Niedermayer 07master:65e73bc60f98: vf_interlace: implement frame rate
[14:58:33 CET] <cone-684> ffmpeg 03Hendrik Leppkes 07master:b2a8c8538d59: Merge commit '65e73bc60f98dc7b26c687e145dfb755d3f2ccfa'
[14:59:44 CET] <cone-684> ffmpeg 03Michael Niedermayer 07master:7d12cba95ca1: vf_framepack: Check and update frame_rate
[14:59:45 CET] <cone-684> ffmpeg 03Hendrik Leppkes 07master:1cb78a0dcfd0: Merge commit '7d12cba95ca15198a930c05458dc414ac00c578b'
[15:00:20 CET] <cone-684> ffmpeg 03Michael Niedermayer 07master:11f87ca71e9c: vf_frei0r: also set AVFilterLink.frame_rate
[15:00:21 CET] <cone-684> ffmpeg 03Hendrik Leppkes 07master:1b86a6bb2cea: Merge commit '11f87ca71e9c7b917f594194f827fd040d1df5ca'
[15:02:17 CET] <cone-684> ffmpeg 03Michael Niedermayer 07master:1339009c4924: vf_showinfo: show timebase & framerate too
[15:02:18 CET] <cone-684> ffmpeg 03Hendrik Leppkes 07master:51a3e525935e: Merge commit '1339009c4924a20e872aa62897097bf5d071157c'
[15:03:32 CET] <cone-684> ffmpeg 03John Stebbins 07master:db9b7321d5df: vsrc_color: implement frame rate
[15:03:33 CET] <cone-684> ffmpeg 03Hendrik Leppkes 07master:1f185ed897dd: Merge commit 'db9b7321d5dfcbaf521d46beec44cf724776c70d'
[15:04:42 CET] <cone-684> ffmpeg 03Martin Storsjö 07master:8ad5124b7ecf: movenc: Automatically flush after writing the initial moov
[15:04:43 CET] <cone-684> ffmpeg 03Hendrik Leppkes 07master:9ffc61b1256e: Merge commit '8ad5124b7ecf7f727724e270a7b4bb8c7bcbf6a4'
[15:09:59 CET] <wm4> also, libavresample does not have the problem
[15:10:12 CET] <nevcairiel> guess i'm not merging the movenc unit test because it fails in various random ways o.o
[15:10:44 CET] <nevcairiel> cba to investigate now, maybe another day
[15:11:17 CET] <kierank> nevcairiel: libav wrote a unit test or is it ludmila's?
[15:11:24 CET] <wm4> ah no, libavresample is using another code path
[15:11:29 CET] <nevcairiel> kierank: wbs wrote it
[15:11:32 CET] <kierank> ah
[15:12:46 CET] <wm4> ok lavr has the same problem
[15:13:02 CET] <nevcairiel> maybe you're expecting something that it doesnt actually do
[15:13:24 CET] <wm4> nevcairiel: I'm unable to answer this question as well
[15:13:57 CET] <cone-684> ffmpeg 03Michael Niedermayer 07master:46070cc20aa3: ffmpeg: set muxer packet duration based on framerate only for CFR
[15:13:58 CET] <cone-684> ffmpeg 03Michael Niedermayer 07master:363673fbe0e1: ffmpeg: Print a warning if a pkt duration is already set before using the frame rate
[15:19:14 CET] <durandal_1707> wm4: what are you doing?
[15:19:28 CET] <wm4> resampling
[15:19:37 CET] <wm4> to change audio speed
[15:21:34 CET] <wm4> and there was a huge drift, which I concluded is caused by swr_set_compensation not being exact
[15:22:03 CET] <wm4> (only happens sometimes)
[15:54:38 CET] <wm4> hm, I guess swr_set_compensation really wants the actual length for compensation_distance, not the compensated length?
[15:55:18 CET] <wm4> the full documentation for this is "number of samples to compensate for", whatever that means
[15:56:02 CET] <wm4> going by the code passing the not-compensated length makes sort of sense I guess
[15:56:26 CET] <wm4> but only for the ratio calculation
[16:07:57 CET] <wm4> michaelni_: so which is it
[17:59:59 CET] <cone-684> ffmpeg 03Michael Niedermayer 07master:64e220beb5fb: ffserver: Do not add or rescale AV_NOPTS_VALUE from the demuxer
[18:00:00 CET] <cone-684> ffmpeg 03Michael Niedermayer 07master:6770a9d6898a: ffmpeg: Fix integer overflow with cur_dts being AV_NOPTS_VALUE
[18:07:50 CET] <wm4> michaelni_: do you think an API like swr_set_compensation_ratio(ctx, num, den) would be good
[18:15:05 CET] <fritsch> wm4: did you check how we use it?
[18:15:14 CET] <fritsch> works since some releases (if it matters) :-)
[18:15:22 CET] <wm4> fritsch: yes, I think it's wrong
[18:15:27 CET] <wm4> same in ffplay.c
[18:16:16 CET] <wm4> or maybe it's not wrong (hard to tell)
[18:16:27 CET] <wm4> the problem is with rounding errors which can accumulate
[18:17:57 CET] <fritsch> okay - for us it works quite well
[18:18:09 CET] <fritsch> and we compare against a vblank timer
[18:18:13 CET] <fritsch> and measure what to resample
[18:18:41 CET] <fritsch> also when logging the resample ratio - it it's most of the time constant the 4 digits behind the dot
[18:18:46 CET] <fritsch> but I will follow this discussion
[18:18:53 CET] <fritsch> btw. this public method was added after we started to use it
[18:23:04 CET] <wm4> this function (or an older version of it) was part of the initial swr commit
[18:29:44 CET] <wm4> anyway, it's pretty certain that swr_set_compensation() can't handle arbitrary ratios correctly, because it essentially only adjusts the numerator of the resample ratio
[18:30:03 CET] <wm4> so the resolution can be too low
[18:30:36 CET] <wm4> so unless you do extra compensation (like keeping track of the sample input/output ratio of the resampler), it will drift
[18:30:42 CET] <wm4> (and quite a lot)
[18:32:17 CET] <fritsch> yeah can only say, we use it "straight forward"
[18:32:22 CET] <fritsch> and it's okay for now
[18:32:36 CET] <fritsch> what is "a lot" when you talk about drifting?
[18:32:56 CET] <wm4> the case I observed was 1ms drift per second
[18:33:12 CET] <wm4> it depends on the sample rates and the phase_shift option
[18:33:15 CET] <kierank> wm4: that's massive
[18:33:19 CET] <kierank> 1ms /s 
[18:33:41 CET] <wm4> yes, often it's the value you want to compensate for in the first place
[18:34:33 CET] <wm4> this is the core of the issue: c->dst_incr = c->ideal_dst_incr - c->ideal_dst_incr * (int64_t)sample_delta / compensation_distance;
[18:35:23 CET] <kierank> wm4: iirc mpegts maximum drift is 7.5 * 10^-3
[18:35:26 CET] <kierank> so a bit lower than that
[18:35:43 CET] <fritsch> we use it like: (ctx, (dst_samples*ratio-dst_samples)*m_dst_rate/m_src_rate, dst_samples*m_dst_rate/m_src_rate)
[18:36:06 CET] <wm4> fritsch: this alone doesn't evade the fundamental drift that can happen
[18:36:31 CET] <wm4> if you don't have a problem with this, you probably compensate somewhere else (which is fine and all, but doesn't change that this API is fucking broken)
[18:36:33 CET] <fritsch> can you link me to the code where you call it?
[18:36:42 CET] <wm4> doesn't matter
[18:36:54 CET] <fritsch> if it would really drift that much our "ratio"
[18:36:58 CET] <fritsch> should constantly change
[18:37:54 CET] <wm4> I wonder if soxr_set_io_ratio() works better
[18:39:11 CET] <cone-684> ffmpeg 03Michael Niedermayer 07master:351e625d6016: swresample/resample: increase precision for compensation
[18:39:16 CET] <fritsch> hehe
[18:39:17 CET] <fritsch> ^^
[18:40:59 CET] <fritsch> if it fixes your issue - that would be a good candidate for 2.8 branch, too
[18:41:04 CET] <michaelni_> about swr_set_compensation_ratio(), if people want that, sure, no objections from me
[18:41:25 CET] <wm4> michaelni_: thanks, this commit fixes my use case
[18:41:37 CET] <michaelni_> :)
[18:42:47 CET] <wm4> I wasn't sure if src_incr can really be changed at runtime (maybe not as other stuff depends on it), but that's a nice trick
[20:01:06 CET] <cone-684> ffmpeg 03Michael Niedermayer 07release/2.8:3de8521667e3: swresample/resample: increase precision for compensation
[20:01:49 CET] <fritsch> michaelni_: thx much!
[21:43:36 CET] <cone-684> ffmpeg 03Michael Niedermayer 07master:2ec18db75cff: ffserver: Replace one malloc(AVStream) by avformat_new_stream()
[21:56:48 CET] <cone-684> ffmpeg 03Andreas Cadhalpun 07master:0e36a14a423b: aacsbr_fixed: check for envelope scalefactors overflowing
[21:56:49 CET] <cone-684> ffmpeg 03Andreas Cadhalpun 07master:1675809d2df7: dds: validate source buffer size before copying
[21:56:50 CET] <cone-684> ffmpeg 03Andreas Cadhalpun 07master:9a37d476440d: dds: validate compressed source buffer size
[21:56:51 CET] <cone-684> ffmpeg 03Andreas Cadhalpun 07master:edd0c1d78a89: dds: add missing newline to log messages
[23:37:47 CET] <kierank> That UDP buffer patch is horrid
[23:42:55 CET] <jamrial> kierank: that email was not the best way to welcome new contributors...
[23:43:09 CET] <kierank> it's stupid corporate hack code
[23:43:14 CET] <kierank> awful awful awful
[23:45:18 CET] <jamrial> then at least point what's wrong. they even asked as much
[23:45:20 CET] <JEEB> the patch was attached so while I felt interested when I first noticed the post, I didn't take a look
[23:47:37 CET] <JEEB> oh
[23:47:45 CET] <kierank> ok done
[23:49:15 CET] <jamrial> thanks
[00:00:00 CET] --- Thu Nov 12 2015