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

[burek]

[00:03:41 CEST] <philipl> I just read the updated nvidia driver readme. Although they decided to declare baseline support, they don't support the crazy features, unsurprisingly
[00:05:58 CEST] <BBB> philipl: like constrained intra pred?
[00:06:19 CEST] <philipl> "The NVIDIA VDPAU implementation does not support flexible macroblock ordering, arbitrary slice ordering, redundant slices, data partitioning, SI slices, or SP slices."
[00:08:00 CEST] <rcombs> I've never gotten around to learning what all those things are
[00:08:05 CEST] <rcombs> nor why they're not in Main/High
[00:08:50 CEST] <philipl> They seem to be primarily 'useful' for dealing with extremely unreliable transports where you don't expect to receive intact pictures.
[00:10:15 CEST] <philipl> So you divide your pictures up into independelty decodable regions, and have redundant data, etc, etc.
[00:10:27 CEST] <philipl> Now why the video encoding format is the right way to deal with that kind of thing is beyond me.
[00:10:36 CEST] <philipl> Clearly beyond everyone else too, given the 0% adoption.
[00:11:08 CEST] <philipl> BBB: Tha't an SVC feature right? They don't say anything about SVC.
[00:11:21 CEST] <philipl> Intel vaapi claims to support MVC and SVC. Never tried it though
[00:11:38 CEST] <cone-801> ffmpeg 03Marton Balint 07master:0166d329c3e3: ffplay: add specific constants for buffer fullness settings when using external clock
[00:11:38 CEST] <cone-801> ffmpeg 03Marton Balint 07master:8628b06b317e: ffplay: increase MIN_FRAMES to 25
[00:12:37 CEST] <cone-801> ffmpeg 03Niklesh 07master:d670848d4c27: movtextdec: Use default style information from movtext header
[00:20:36 CEST] <wm4> philipl: I keep wondering about that
[00:20:43 CEST] <wm4> philipl: e.g. how they even return the data
[01:12:57 CEST] <philipl> wm4: One can only imagine.
[01:45:09 CEST] <michaelni> philipl, last commit broke fate-sub-movtext fate-sub-subripenc
[01:55:38 CEST] <michaelni> philipl, should the fate references be updated or something else ?
[02:17:47 CEST] <cone-801> ffmpeg 03Michael Niedermayer 07master:0eb896b38dc5: Revert "movtextdec: Use default style information from movtext header"
[02:19:16 CEST] <michaelni> philipl, i reverted it, the code does odd things and theres different output on x86 & mips both differing from the reference for the fate tests (also see my reply to the patch on ML)
[02:31:32 CEST] <philipl> hmm
[02:32:34 CEST] <philipl> I assumed the three byte copy was leaving an alpha byte untouched.
[02:35:49 CEST] <jamrial> philipl: would AV_W*24 work for that?
[02:36:42 CEST] <philipl> possibly.
[02:51:32 CEST] <cone-801> ffmpeg 03Michael Niedermayer 07master:8c75a338124f: postproc: Deprecate QP_STORE_T, it lacks a PP/AV/FF prefix
[04:54:10 CEST] <cone-801> ffmpeg 03Michael Niedermayer 07master:46f15de8a4ea: avformat/gifdec: correct r_frame_rate for single frame gifs
[10:13:20 CEST] <thardin> is tim ever in here?
[10:14:42 CEST] <thardin> or I guess any other mxf peeps
[10:15:41 CEST] <thardin> thought I'd get a second opinion on marking mxfdec seeking as pts based
[11:14:02 CEST] <cone-469> ffmpeg 03Luca Barbato 07master:0f562f5b833d: h264: Do not print an error when the buffer has to be refilled
[11:14:02 CEST] <cone-469> ffmpeg 03Hendrik Leppkes 07master:b1d547fe024a: Merge commit '0f562f5b833d603e04123d198c59f8b2b5eb43e4'
[11:18:07 CEST] <ubitux> what's the logic ffmpeg adopts for deciding which packets to write in the output when packets are coming from different sources?
[11:18:12 CEST] <ubitux> smallest pkt.pts goes first?
[11:18:38 CEST] <nevcairiel> there is probably some more advanced interleaving logic, but thats probably the major factor
[11:18:49 CEST] <cone-469> ffmpeg 03Paolo Bizzarri 07master:1542ec96389f: cosmetics: Drop spurious spaces from if clauses
[11:18:50 CEST] <cone-469> ffmpeg 03Hendrik Leppkes 07master:e1def4ffec20: Merge commit '1542ec96389f32e5081c6c607e4b6f5e257ccdf2'
[11:18:52 CEST] <ubitux> any idea where this code is located?
[11:19:00 CEST] <ubitux> except that "ffmpeg.c"
[11:19:28 CEST] <nevcairiel> the actual interleaving is in avformat, probably utils.c
[11:19:28 CEST] <ubitux> also wonder how that works with threading
[11:19:36 CEST] <nevcairiel> not sure  which part you are actually looking for
[11:19:51 CEST] <nevcairiel> or mux.c, i think thats a thing
[11:20:12 CEST] <ubitux> well, ffmpeg is most likely not relying on the avformat interleaving when you mux video from one file and audio from another one typically
[11:20:18 CEST] <ubitux> it's not going to send all the video packets to avformat
[11:20:19 CEST] <cone-469> ffmpeg 03Martin Storsjö 07master:8e34089e265a: movenc: Check that frag_info entries exist in mov_write_sidx_tag
[11:20:20 CEST] <cone-469> ffmpeg 03Hendrik Leppkes 07master:6c52432b4812: Merge commit '8e34089e265a6b01e1e3301e8864439d26793753'
[11:20:23 CEST] <ubitux> then all the audio packets
[11:21:45 CEST] <ubitux> there is indeed a queue (max interleave something) in avformat, but that's probably for finer interleave adjustement
[11:22:15 CEST] <ubitux> i'm more curious about the logic of ffmpeg as an api user dealing with distinct where it has to interleave somehow sources
[11:22:33 CEST] <ubitux> (move "sources" before "where")
[11:23:32 CEST] <cone-469> ffmpeg 03Martin Storsjö 07master:83f254e65f93: movenc: Rename reserved_moov_pos to reserved_header_pos
[11:23:33 CEST] <cone-469> ffmpeg 03Hendrik Leppkes 07master:7653ebfff6ea: Merge commit '83f254e65f938657a4dbec711e4c94252a72daf9'
[11:24:08 CEST] <wm4> are you sure it doesn't just buffer all video packets? it would be stupid, but required for good interleraving
[11:24:45 CEST] <ubitux> i'm pretty sure ffmpeg doesn't explode in memory when i stream copy from different inputs
[11:25:05 CEST] <wm4> but it also doesn't create broken files, right?
[11:25:26 CEST] <ubitux> i think so
[11:25:57 CEST] <wm4> then ffmpeg.c must be doing it
[11:25:58 CEST] <ubitux> my guess is that it's controlling what sources need to be demuxed and avoid making a too large shift
[11:26:04 CEST] <wm4> oh, that's what abou asked about
[11:26:07 CEST] <ubitux> then avformat assures exact/proper interleaving
[11:26:15 CEST] <wm4> s/abou/you
[11:26:28 CEST] <ubitux> yeah, i'm curious how it manages to do that
[11:26:46 CEST] <ubitux> and i think it was in place before the threading happened in ffmpeg.c
[11:26:57 CEST] <cone-469> ffmpeg 03Martin Storsjö 07master:5f200bbf98ef: movenc: Place the sidx index after the initial moov/mdat pair
[11:26:59 CEST] <cone-469> ffmpeg 03Hendrik Leppkes 07master:10ea06b3bb86: Merge commit '5f200bbf98efe50f63d0515b115d2ba8dae297bc'
[11:27:54 CEST] <wm4> nevcairiel: nice work with the merging
[11:27:58 CEST] <wm4> nevcairiel: how annoying is it?
[11:28:03 CEST] <nevcairiel> not very
[11:28:11 CEST] <nevcairiel> most changes apply easy enough
[11:28:25 CEST] <ubitux> wait for the incoming pixel format negociation in lavfi
[11:28:54 CEST] <ubitux> and anyway yeah, thank you for doing this
[11:29:21 CEST] <wm4> <ubitux> wait for the incoming pixel format negociation in lavfi <- they're about to duplicate even their own code
[11:29:52 CEST] <nevcairiel> and when called out on it, the answer was "I'll just commit this, and then clean it up later" =p
[11:29:56 CEST] <nevcairiel> how unclean of them
[11:30:14 CEST] <wm4> I needed to point it out twice, too
[11:30:17 CEST] <cone-469> ffmpeg 03Paul B Mahol 07master:7a7ca3cc2f43: avfilter/vsrc_testsrc: smpte(hd)bars: fix uninitialized last rows and columns of chroma planes
[13:04:55 CEST] <michaelni> ubitux, about SAMI_multilang_tweak_tester.smi vs. SAMI_ass_capability_tester.smi, should i upload the duplicate file ?
[14:13:14 CEST] <BBB> JEEB: have you had time to look at the #libav logs?
[14:27:37 CEST] <ubitux> > Now realize that Calligra has 609 CMakeLists.txt files
[14:27:41 CEST] <ubitux> someone is looking for troubles
[14:29:31 CEST] <wm4> wow
[14:29:55 CEST] <wm4> I sure love bloated cmake files full of repeated broken code, which do the same thing pkg-config could do in 2 lines
[14:32:04 CEST] <nevcairiel> that blog post was silly, that guy is that kind of developer i hate, considering all libraries god given and instead of appreciating constant maintenance on the libs, hating on every change
[14:32:38 CEST] <nevcairiel> (and considering its not that hard to write an app that works with both qt4 and qt5, probably also terrible code in his project :P)
[14:35:48 CEST] <wm4> to be fair, sometimes API changes can look very pointless and downstreams also won't appreciate that they have to change their code
[14:36:52 CEST] <nevcairiel> If i get to avoid having to write my own h264 decoder, I tend to be a bit forgiving, all the API changes in the world wouldn't come close to the effort saved
[14:40:52 CEST] <wm4> yeah, but they will think "why the fuck did you have to change this fine library, now I have to spend an afternoon to fix my perfectly working code... oh fuck and the new code doesn't work on debian's current libav package!"
[14:55:24 CEST] <BBB> and next they complain about poor quality and low speed
[14:59:16 CEST] <Daemon404> the only change which pisses me off to this day for libav*
[14:59:22 CEST] <Daemon404> is #define'ing CodecID
[14:59:24 CEST] <Daemon404> which is VERY generic
[14:59:56 CEST] <Daemon404> and the errors it produces are confusing at best for downstream
[15:00:03 CEST] <Daemon404> since it is a define, the compiler is confused
[15:00:13 CEST] <wm4> how did this ever work in codebases where there's a conflict?
[15:00:22 CEST] <wm4> C++?
[15:01:17 CEST] <Daemon404> https://github.com/FFMS/ffms2/blob/f8edbc36a20c9b782f54fc835e0dd1628d45a720/include/ffmscompat.h#L59-L66
[15:15:28 CEST] <nevcairiel> wm4: for me it just renamed it in one file, and i didnt even notice until i went into a debuffer and wondered where the hell the AV prefix comes from =p
[15:15:47 CEST] <nevcairiel> probably some cases where it will even result in build failure though
[15:20:16 CEST] <Daemon404> nevcairiel, see, that's an evil sort of failure
[15:20:42 CEST] <nevcairiel> it didnt actually break anything, and not like C has reflections where the names of things are important
[15:20:43 CEST] <nevcairiel> but yeah
[15:32:25 CEST] <nevcairiel> the same goes for the PixelFormat define we still have today, but that one seemed to trip up much less often
[15:32:51 CEST] <Daemon404> yes
[15:34:02 CEST] <ubitux> because deprecated warning are raised maybe?
[15:36:11 CEST] <Daemon404> ubitux, ?
[15:36:15 CEST] <Daemon404> the CodecID define is silent.
[15:36:25 CEST] <Daemon404> any downstream code using that generic name internally will silently fuck u
[15:36:28 CEST] <Daemon404> p
[15:37:25 CEST] <iive> well, what are the odds that there is a project that is using CodecID for its own things and just now it tries to use ffmpeg?
[15:37:37 CEST] <Daemon404> ?
[15:37:43 CEST] <Daemon404> tons of projects use CodecID internally
[15:37:44 CEST] <nevcairiel> it happened so several projects
[15:38:07 CEST] <Daemon404> any framework is going to have its own codec ids
[15:38:13 CEST] <Daemon404> that you need to map to lavf
[15:38:14 CEST] <Daemon404> for example.
[15:38:16 CEST] <iive> any project that have been using ffmpeg should have already ironed out that thing.
[15:38:22 CEST] <Daemon404> wut?
[15:38:29 CEST] <Daemon404> in what sense
[15:38:34 CEST] <Daemon404> it was a silent update
[15:38:39 CEST] <Daemon404> iirc it wasn teven listed in APIChanges
[15:38:53 CEST] <iive> oh, my bad.
[15:39:07 CEST] <Daemon404> i think the define is gone now anyway
[15:39:10 CEST] <Daemon404> at the time i was annoyed
[15:39:29 CEST] <nevcairiel> CodecID is gone yes
[15:39:41 CEST] <nevcairiel> i forgot why we even used a define instead of a typdef
[15:39:46 CEST] <nevcairiel> there probably was some convoluted reason
[15:39:52 CEST] <Daemon404> elenril had some convoluted reason
[15:42:04 CEST] <ubitux> Daemon404: ok
[15:42:50 CEST] <ubitux> michaelni: yes please keep the second name
[15:46:46 CEST] <michaelni> ubitux, just to make sure i dont misunderstand "yes i should upload" or "i should not and keep the 2nd file already in the fate suite" ?
[15:47:38 CEST] <ubitux> rm fate-suite/sub/SAMI_ass_capability_tester.smi; mv SAMI_multilang_tweak_tester.smi fate-suite/sub/ 
[15:55:23 CEST] <durandal_170> ubitux: I added log scale to frequency axis
[15:56:12 CEST] <ubitux> so the representation of high freq are boosted?
[15:57:19 CEST] <ubitux> what's the point of configuring the win size btw? you're making rectangle for smaller windows and averaging for larger ones?
[15:58:16 CEST] <ubitux> (testing soon)
[16:01:46 CEST] <ubitux> small windows are very laggy
[16:01:51 CEST] <ubitux> expected?
[16:03:11 CEST] <ubitux> fscale is curious heh
[16:04:00 CEST] <Daemon404> win size?
[16:04:43 CEST] <ubitux> number of sample in the fft
[16:05:09 CEST] <ubitux> but i suppose running a lot of fft for a frame is making it slow
[16:05:13 CEST] <Daemon404> oh.
[16:07:54 CEST] <ubitux> heh, i like how libvpx farts on the colors when trying to encode a demo of this filter
[16:08:34 CEST] <ubitux> i see shades of blue and purple
[16:08:50 CEST] <ubitux> even though the input only has 4 colors (black orange green red)
[16:15:00 CEST] <durandal_170> ubitux: if they overwrite each other they are ored
[16:15:38 CEST] <durandal_170> But could do something similar as in drawgraph
[16:16:18 CEST] <durandal_170> log for fscale is for lower frequencies
[16:17:27 CEST] <durandal_170> Imho line mode is more useful
[16:19:27 CEST] <durandal_170> I could add background color and draw grid
[16:20:08 CEST] <ubitux> if you set a small window size, you get really a shit ton of frames
[16:20:13 CEST] <ubitux> (obviously)
[16:20:33 CEST] <ubitux> you might want to average them or something
[16:20:39 CEST] <ubitux> but might get complex
[16:20:59 CEST] <ubitux> i guess adding a asetnsamples after the filter would help
[16:21:29 CEST] <ubitux> ah, my bad no you can't it's a video output&
[16:21:44 CEST] <ubitux> so you can only drop
[16:27:16 CEST] <michaelni> ubitux, uploded
[16:27:23 CEST] <ubitux> michaelni: thx
[17:00:20 CEST] <Daemon404> g 42
[17:13:53 CEST] <kierank> thardin: tim is on holiday for 3 weeks
[17:17:08 CEST] <ubitux> http://lucy.pkh.me/showfreqs.webm
[17:17:31 CEST] <ubitux> (i'm dropping frames here)
[17:17:44 CEST] <ubitux> (showfreqs=win_size=w64,fps=25)
[17:18:39 CEST] <ubitux> it seems there is a glitch in the first sample sometimes
[17:26:37 CEST] <kierank> dericed: ping
[17:29:01 CEST] <durandal_1707> ubitux: for this filter you need 8k display
[17:47:06 CEST] <kierank> https://usercontent.irccloud-cdn.com/file/QUeMJChs/IMG_20150810_164556.jpg
[17:49:46 CEST] <cone-469> ffmpeg 03Michael Niedermayer 07master:b26497f82424: avcodec/mjpegenc_common: do not ignore the color_range field
[17:51:09 CEST] <kierank> durandal_1707: 4:47 PM <"kierank> https://usercontent.irccloud-cdn.com/file/QUeMJChs/IMG_20150810_164556.jpg
[17:51:13 CEST] <kierank> something is slightly wrong
[17:51:40 CEST] <nevcairiel> looks like it hits the squares
[17:51:56 CEST] <nevcairiel> if thats what its supposed to do
[17:54:29 CEST] <kierank> yes but there's that broken signal in the bakground
[17:55:01 CEST] <kierank> and if you put it to analogue mode it looks even weirder
[17:55:28 CEST] <thardin> kierank: ah
[17:56:10 CEST] <nevcairiel> the echos look like aliasing in the signal
[17:56:57 CEST] <durandal_1707> kierank: this is smptebar?
[17:57:11 CEST] <nevcairiel> does it go through any f ormat conversions? probably swscale rgb transform?
[17:57:22 CEST] <kierank> durandal_1707: yes
[17:57:26 CEST] <kierank> no, all uyvy422 
[17:58:00 CEST] <durandal_1707> maybe chroma is misaligned
[17:58:07 CEST] <kierank> oh wait there seems to be some swscale functions called
[17:58:39 CEST] <kierank> durandal_1707: can smptebars generate uyvy422 natively?
[17:58:56 CEST] <durandal_1707> nope only planar
[17:59:07 CEST] <kierank> bugger
[17:59:27 CEST] Action: kierank doesn't trust swscale to convert properly
[17:59:37 CEST] <durandal_1707> there should be planar equivalent?
[17:59:40 CEST] <nevcairiel> enable swscale info printing and verify it uses the planar->packed special converter
[17:59:53 CEST] <nevcairiel> if there is such a thing for yuv422p -> uyvy422
[18:00:02 CEST] <durandal_1707> and unscaled converter
[18:00:03 CEST] <kierank> the output hardware takes packed
[18:00:04 CEST] <nevcairiel> the generic path probably clobbers your image
[18:00:57 CEST] <nevcairiel> seems like there is such a thing
[18:01:02 CEST] <nevcairiel> and it should usually auto-select it
[18:01:09 CEST] <nevcairiel> but better verify =)
[18:01:25 CEST] <kierank> ah yes it's better with unscaled path
[18:01:38 CEST] <kierank> But not exact
[18:03:15 CEST] <nevcairiel> unscaled should at least result in a bitexact byte reshuffling
[18:03:57 CEST] <kierank> https://usercontent.irccloud-cdn.com/file/sjmSa7ph/irccloudcapture-1857613335.jpg
[18:03:57 CEST] <kierank> yeah
[18:04:06 CEST] <nevcairiel> the aliasing is gone, hooray
[18:04:08 CEST] <kierank> I'm not sure if there's meant to be a line going across
[18:08:27 CEST] <nevcairiel> dont you have a reference to compare to
[18:09:42 CEST] <durandal_1707> those are +i and q
[18:10:01 CEST] <durandal_1707> I think
[18:12:42 CEST] <kierank> https://usercontent.irccloud-cdn.com/file/xvLwo2IK/irccloudcapture-405417868.jpg
[18:12:56 CEST] <kierank> I figured out how to get the graticule
[18:14:31 CEST] <kierank> I think *technically* there should be a smooth transition between colours
[18:14:35 CEST] <kierank> but I don't care about that 
[18:14:39 CEST] <kierank> because that's an analogue thing
[18:17:52 CEST] <durandal_1707> I didn't toke I and q from dveo, should I?
[18:18:49 CEST] <kierank> please send a patch and I will try
[18:18:56 CEST] <kierank> I'm curious to see which will be better
[18:27:37 CEST] <kierank> durandal_1707: 
[18:27:37 CEST] <kierank> 5:26 PM <mdsh> I believe the point is not the exact values but the relationship between the two
[18:38:57 CEST] <wm4> what sorcery is this anyway? is it physically measuring the output of some reference screen?
[18:39:51 CEST] <durandal_1707> kierank: sent on ml
[18:41:24 CEST] <nevcairiel> wm4: probably directly from the output of some hardware, not from a screen
[18:41:57 CEST] <nevcairiel> ie. feed yuv422 output hardware into scopre
[18:41:59 CEST] <nevcairiel> -r
[18:42:05 CEST] <kierank> https://usercontent.irccloud-cdn.com/file/pkPaJG3G/irccloudcapture177591402.jpg
[18:42:10 CEST] <kierank> very slight difference
[18:44:44 CEST] <kierank> durandal_170: new patch is better
[18:46:16 CEST] <kierank> wm4: it's an analogue-style measurement
[18:46:20 CEST] <cone-469> ffmpeg 03Lukasz Marek 07master:bc9305316142: lavf/ftp: implement directory listing callbacks
[18:46:21 CEST] <cone-469> ffmpeg 03Mariusz SzczepaDczyk 07master:ee44cb3c81a9: lavf/ftp: properly read an empty path
[18:46:23 CEST] <kierank> to make sure the colours match
[18:59:33 CEST] <cone-469> ffmpeg 03Michael Niedermayer 07master:55a07cf49c00: avformat/ftp: Use av_freep() for dir_buffer
[19:09:42 CEST] <nevcairiel> i find it funny that we have this directory listing api, but it doesnt even support the file protocol
[19:09:50 CEST] <nevcairiel> i would've figured thats what i start with =p
[19:38:51 CEST] <BBB> nevcairiel: send a patch"
[19:59:50 CEST] <ebail>  Hi guys, I just post a question about RTCP infos extraction on mailing list (http://ffmpeg.org/pipermail/libav-user/2015-August/008379.html). I wonder if it would need an additional dev or if I am wrong. Thanks.
[20:03:00 CEST] <durandal_1707> does it make sense to port smpte rp155 as audio source?
[20:15:02 CEST] <kierank> durandal_1707: If its a 1khz tone it can be done with aevalsrc
[20:15:36 CEST] <kierank> But I couldn't use it because I need an exact number of samples
[20:17:21 CEST] <durandal_1707> sine can do it but there is 1second of silence, also you can use asetnsamples
[20:19:09 CEST] <kierank> I need it variable
[20:19:31 CEST] <kierank> Because of NTSC
[20:20:07 CEST] <kierank> So 1601,1602,1601 pattern
[20:31:17 CEST] <ubitux> doesn't support eval?
[20:31:36 CEST] <ubitux> or maybe timeline so you stack two of them?
[20:33:31 CEST] <ubitux> bte, sine might be better than aevalsrc for that
[20:36:11 CEST] <ubitux> actually that might be possible with a hack
[20:38:10 CEST] <ubitux> or maybe not
[20:40:52 CEST] <ubitux> kierank: you can hack easily the number of samples in sine filter
[20:41:10 CEST] <ubitux> or do it properly by changing it as an eval expression
[20:48:53 CEST] <ubitux> almost done a PoC actually
[20:49:59 CEST] <durandal_1707> what?
[20:50:33 CEST] <durandal_1707> kierank: do you have paper?
[20:56:53 CEST] <ubitux> kierank: so what's the exact pattern? 1601,1602 repeated or 1601,1602,1061 repeated?
[21:02:28 CEST] <ubitux> ok done
[21:04:03 CEST] <ubitux> kierank: http://b.pkh.me/0001-avfilter-sine-support-expression-in-the-number-of-ou.patch
[21:04:23 CEST] <ubitux> then ffmpeg -f lavfi -i "sine=1000:samples_per_frame='print(1601+bitand(N,1))'" ...
[21:04:37 CEST] <ubitux> you can drop the print obviously
[21:11:22 CEST] <ubitux> i suppose that's 1602,1601,1602,1601,1602 for 30/1.001? 
[21:11:44 CEST] <ubitux> the expression needs to be adjusted then
[21:14:53 CEST] <ubitux> something like st(0,mod(N,5)); 1602-not(not(eq(ld(0),0)+eq(ld(0),3)))
[21:15:02 CEST] <ubitux> (untested)
[21:19:22 CEST] <ubitux> sorry typo
[21:19:29 CEST] <ubitux> st(0,mod(N,5)); 1602-not(not(eq(ld(0),1)+eq(ld(0),3)))
[21:19:31 CEST] <ubitux> this works
[21:20:00 CEST] <ubitux> ffmpeg -f lavfi -i "sine=1000:samples_per_frame='print(st(0,mod(N,5)); 1602-not(not(eq(ld(0),1)+eq(ld(0),3))))'" ...
[21:20:34 CEST] <Daemon404> this is all i see ubitux typing: http://33.media.tumblr.com/ef86987cc27600cf449df78ce4243c74/tumblr_mfjlubENIJ1qgmkv3o1_500.gif
[21:20:40 CEST] Action: Daemon404 runs
[21:20:45 CEST] <ubitux> haha
[21:20:56 CEST] <ubitux> i'm sure you can understand the expression with little effort :)
[21:21:00 CEST] <Daemon404> yeah sure
[21:21:08 CEST] <Daemon404> not one you escape it for the shell though
[21:21:10 CEST] <Daemon404> once*
[21:21:19 CEST] <ubitux> no need to
[21:21:24 CEST] <ubitux> there is ''
[21:21:36 CEST] <Daemon404> oh indeed.
[21:21:43 CEST] Action: Daemon404 invents a shell that doesnt allow '
[21:22:07 CEST] <ubitux> and the expression is simply: store N%5 in register 0, then 1602 - (reg(0)==1 ||  reg(0)==3)
[21:23:03 CEST] <Daemon404> i was hoping i was wrong about the assembly semantics.
[21:23:08 CEST] <ubitux> (actually 1602 - !!((reg(0)==1) + (reg(0)==3)) because there is no OR)
[21:23:27 CEST] <ubitux> i can save one ! easily
[21:23:37 CEST] <ubitux> but who cares
[21:24:33 CEST] <ubitux> Daemon404: it might not work with tcsh yeah
[21:24:46 CEST] <ubitux> but -filter_script is your friend then
[21:25:41 CEST] <Daemon404> people use tcsh?
[21:26:28 CEST] <ubitux> don't underestimate them
[21:29:48 CEST] <BBB> ebail: youre correct, to the best of my knowledge theyre not exposed
[21:46:43 CEST] <llogan> durandal_1707: do you have a twitter account?
[21:47:01 CEST] <durandal_1707> Nope
[21:47:04 CEST] <llogan> i want to mention how many filters you've made in that last ~month
[21:47:25 CEST] <durandal_1707> I have g+
[21:50:02 CEST] <llogan> damn...too many characters to list them all
[21:56:13 CEST] <BBB> llogan: lol
[21:57:07 CEST] <ebail> BBB: any advice to expose it ?
[21:57:27 CEST] <BBB> ebail: like you said, add it to metadata dict
[21:57:37 CEST] <BBB> ebail: in whatever form is useful for you
[22:10:21 CEST] <ebail> BBB: ok. So it would be the responsabiliy of the application to read dict at time, i.e before a new RTCP report is received ? 
[22:14:04 CEST] <BBB> if you dont want to lose previous one, yes
[22:14:14 CEST] <BBB> but I mean, this is just for display, right? then it doesnt matter if you lose 1
[22:14:26 CEST] <BBB> ifyou want to do stuff with it, you would want ot do that inside libavformat, not in your app
[22:18:06 CEST] <ebail> BBB: not only for display. I want to implement a simple algorithm on top that will change the encoder bitrate
[22:19:13 CEST] <ebail> so that we will converge on highest bitrate without packet drops
[22:20:00 CEST] <BBB> right, you want to do that inside libavformat
[22:20:04 CEST] <BBB> dont do that in your application
[22:22:27 CEST] <ebail> BBB: to change bitrate, I could not find a better way than restarting completely encoder with new bitrate. So lot of stuff are anyway done in my app
[22:22:55 CEST] <BBB> uhm& ok
[22:23:09 CEST] <BBB> you know thats kind of inefficient, right?
[22:23:22 CEST] <BBB> its like using a nuke to kill a fly
[22:23:26 CEST] <BBB> it works, sure& but ...
[22:23:43 CEST] <wm4> enterprise corps have enough money to pay the nukes!
[22:23:45 CEST] <BBB> reminds me of that 90s game called worms
[22:24:32 CEST] <nevcairiel> 90s game? they still make those!
[22:24:37 CEST] <nevcairiel> and its still fun :d
[22:24:47 CEST] <ebail> BBB: what would be your solution so ?
[22:24:50 CEST] <wm4> wasn't Worms 3D not fun?
[22:25:25 CEST] <BBB> ebail: well, for one, restarting means you have to send a new keyframe
[22:25:28 CEST] <BBB> thats hugely inefficient
[22:26:03 CEST] <BBB> ebail: so Id just add a transport stream connection and send requests for bitrate changes over there
[22:26:07 CEST] <ebail> BBB: true. But I was not able to change bitrate in live
[22:26:14 CEST] <BBB> why not
[22:26:44 CEST] <nevcairiel> x264 supports bitrate changes on the fly
[22:27:07 CEST] <BBB> any non-toy encoder should support that...
[22:27:17 CEST] <ebail> hum interresting. 
[22:27:37 CEST] <ebail> could you develop a bit the way to do it ?
[22:27:54 CEST] <BBB> develop=elaborate?
[22:27:57 CEST] <ebail> :)
[22:28:02 CEST] <ebail> yep sorry
[22:29:48 CEST] <BBB> look at x264_encoder_reconfig
[22:29:57 CEST] <BBB> (assuming you use x264)
[22:30:50 CEST] <ebail> BBB: I do. But I also use vpx and mpeg4
[22:31:18 CEST] <nevcairiel> vpx is more of a toy encoder, so it might not support that =p
[22:32:37 CEST] <BBB> oh come on, vpx is used in hangouts
[22:32:45 CEST] <BBB> so it will support it in some way
[22:32:53 CEST] <ebail> hangout do it. true
[22:32:54 CEST] <BBB> mpeg4& I dont know, depends on encoder I guess
[22:32:55 CEST] <BBB> ffmpeg4?
[22:33:00 CEST] <nevcairiel> is that why hangouts is so terrible
[22:33:20 CEST] <BBB> I like it
[22:33:45 CEST] <ebail> BTW I am working on ring. A DHT based communication soft (ring.cx), formely know as sflphone
[22:35:43 CEST] <ebail> I think for the moment, we will keep our 'ugly' encoder restart. But I will definitely look to x264_encoder_reconfig. Regarding RTCP, I will work on how to export RTCP RR values by av_opt
[22:37:09 CEST] <llogan> heh, worms. "Oh, there were batt'ries left."
[23:20:02 CEST] <BBB> ebail: sure, dont feel forced to do anything :)
[23:23:29 CEST] <ebail> BBB: sure. But your advices are good. Thanks. I have to finish something and will work on it ASAP.
[00:00:00 CEST] --- Tue Aug 11 2015