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

[burek]

[01:44:02 CET] <ethe> Do the GSoC things have to be done for GSoC? The only reason I'm asking is that, I'm not eligible for GSoC (at least I think I'm not), but I'm interested in one of the tasks (AAC one).
[01:47:51 CET] <iive> ethe: The tasks are created by FFmpeg, google just approves them.
[01:50:38 CET] <ethe> Yeah, but maybe they'd like actual GSoC candidates to get full choice, there's no point two people doing the same task. Just wondering, I find it's better to ask than to have complications later.
[01:50:52 CET] <iive> ethe: this means, that google have to accept the task first, then a student must be picked... and when he is done he will get his payment.
[01:51:26 CET] <iive> yeh.. it would be bad if two people are working on same thing, gsoc or not. especially if one of them expect to be paid for it.
[01:53:18 CET] <iive> i don't remember is ffmpeg participated in last year gsoc... I think it did., didn't it?
[01:53:27 CET] <ethe> I just checked, I am definitely not eligible for GSoC, you have to have finished secondary education. (personally, I think this is a silly requirement, but whatever)
[01:54:57 CET] <iive> indeed...
[01:55:08 CET] <iive> if you can handle the task...
[02:04:47 CET] <michaelni> ethe, theres also outreachy, which ffmpeg is also participating in. And the aac task has actually no mentor so a gsoc student couldnt even do it currently. that is if you want to work on that it shouldnt conflict with anything
[02:06:48 CET] <cone-349> ffmpeg 03Michael Niedermayer 07master:98a0053d0f90: avcodec/h264: Execute error concealment before marking the frame as done.
[02:08:40 CET] <ethe> michaelni that seems exclusively for women (and minorities)
[02:11:35 CET] <michaelni> ethe, yes, all these things have some eligibility constraints ...
[02:14:12 CET] <ethe> Unfortunately I don't think I'm eligible for any, not that it really matters, I wasn't interested in joining any of them. I just wanted to see if I could do the task, I'm more interested in learning, and AAC was one of the things I wanted to learn about
[02:15:00 CET] <michaelni> you can, but without gsoc/outreahcy its volunteer work so you would not get any money 
[02:16:16 CET] <michaelni> thats the same with almost everyone working on FFmpeg, its all unpaid work we do :)
[02:25:20 CET] <michaelni> also atomnuker and Claudio Freire know aac (more encoder side though), so if you have questions about AAC they might know the awnsers
[02:50:20 CET] <Timothy_Gu> michaelni: http://fatebeta.ffmpeg.org/report/armv7l-panda-gcc4.4-armv4t/20160122221842 looks odd
[02:50:33 CET] <Timothy_Gu> the date is a month ago, but the revision is 3 days old
[02:52:24 CET] <Timothy_Gu> hmm looking at http://fatebeta.ffmpeg.org/history/armv7l-panda-gcc4.4-armv4t with descending sort for revision the date setting looks all messed up
[03:18:59 CET] <Timothy_Gu> RiCON: thanks, fixed
[03:19:20 CET] <michaelni> Timothy_Gu, date fixed on panda arm board
[03:19:27 CET] <Timothy_Gu> cool thanks
[08:23:59 CET] <Timothy_Gu> https://github.com/blog/2111-issue-and-pull-request-templates
[08:29:33 CET] <CoJaBo> yuv4mpegpipe doesn't support yuvj420p; is this a bug, or is it intended for some convoluted reason?
[08:30:17 CET] <wm4_> CoJaBo: tried yuv420p + setting color_range?
[08:31:01 CET] <CoJaBo> I want to minimize the number of color format conversions
[08:34:08 CET] <wm4_> yuvj is deprecated, setting the range is the preferred replacement
[08:34:31 CET] <CoJaBo> ..how do i do that?
[08:35:26 CET] <wm4_> hm just looked, our yuv4mpegenc doesn't check color range, so signalling full range is probably completely unsupported
[08:35:43 CET] <CoJaBo> I can't find much of anything on either color_range or yuvj >_>
[08:40:08 CET] <JEEB> raw video colorimetry beyond ycbcr/rgb and bit depth is usually not supported in containers, if even that
[08:43:02 CET] <JEEB> also of yoi need pipe'able container for raw video I do recommend nut nowadays due to how it also has timestamps and can contain audio. also if it uses the yuvj identifier to write the type of data included it might even work with full range by chance (usually thus stuff is recorded in the video format rather than the container)
[08:55:03 CET] <CoJaBo> JEEB: ..what is yuvj and full-range anyway? is this supposed to be documented somewhere?
[08:59:36 CET] <JEEB> full/tv range. with ycbcr it's 0-255 (rare) vs 16-235/240 (the usual)
[08:59:45 CET] <JEEB> tv or limited range
[09:00:49 CET] <JEEB> basically historical artifacts of digital video that are not going away any time soon
[09:07:00 CET] <jrosser> consider any fir filer on video, it will introduce under/overshoot
[09:07:15 CET] <jrosser> thats why the headroom above and below black and white is there
[09:07:35 CET] <jrosser> so its very relevant today, not just historical
[09:28:27 CET] <JEEB> jrosser: yeah but usually those filtering steps are done in float and the output of the filter should then be limited to the proper range for output of that filter. so for in and out parts it shouldn't really matter.
[09:29:24 CET] <jrosser> there is a widely held misconception that tv range video should be clamped to 16-235, thats not the case
[09:29:59 CET] <jrosser> this is all in Poyntons excellent book
[09:30:10 CET] <JEEB> well the only cases where I've seen actual content outside the range have been mastering fuck-ups
[09:30:33 CET] <JEEB> I know if you want to keep the output between filters it can be useful (like, including the overshoot)
[09:30:47 CET] <JEEB> but in that case I'd think the stuff would be in float for the duration of the filtering chain
[09:30:56 CET] <flux> clamping is not as nice as not clamping.. :)
[09:31:24 CET] <jrosser> you are thinking software, in a tv facility where its all hardware/FPGA and integer arithmetic....
[09:31:31 CET] <JEEB> well sure :P
[09:31:37 CET] <jrosser> anyway, preserving that headroom is agood thing
[09:31:51 CET] <jrosser> and clamping it once at mastering / before TX is alos likely a good thing
[09:32:03 CET] <wm4_> what do you do with out of range rgb anyway
[09:32:16 CET] <jrosser> but doing it all over the place has implications for frequency domain badness
[09:32:20 CET] <JEEB> yes, sure
[09:32:20 CET] <flux> you show blacker black and whiter white!
[09:32:23 CET] <JEEB> I do agree with that
[09:33:08 CET] <JEEB> just that a general user should only get stuff within that range, be it a mastering person encoding a blu-ray/archival version or getting a broadcast that is properly within the range
[09:34:02 CET] <jrosser> test card has above white and below black spots to set up your screen properly
[09:34:10 CET] <jrosser> so we really should pass that everywhere
[09:37:28 CET] <nevcairiel> setup  properly = not visible? :d
[09:38:08 CET] <nevcairiel> some  users make a huge deal out of absolutely requiring the BTB/WTW values to be delivered to their screen, while a properly calibrated screen should probably never be able to show them
[09:40:06 CET] Action: jrosser backs away from this - theres ways you do setup in a broadcast facility which are confusing/irellevant to home environments
[10:00:05 CET] <JEEB> do we have any current examples of having a library-based muxer?
[10:00:31 CET] <JEEB> because I'm currently not sure if I want to expand our current movenc, or add a muxer (ab)using L-SMASH, which already supports some stuff
[10:05:05 CET] <wm4_> isn't the problem that multiple muxers/demuxers are not possible with the API or something (or was that only with regards to demuxers & probing or so)
[10:05:47 CET] <nevcairiel> its possible but you need to explicitly request  them
[10:48:35 CET] <cone-088> ffmpeg 03Paul B Mahol 07master:4956dc88d1fe: avcodec/cdxl: add support for raw videos with chunky format
[11:07:31 CET] <wm4_> meh, so much h264 annexb bsf usage in decoders
[11:11:35 CET] <wm4_> mateo`: what exactly does the mediacodec h264 decoder require for input?
[11:14:42 CET] <mateo`> h264 bitstream - annex b
[11:15:45 CET] <wm4_> mateo`: so what's all that messing with the parser?
[11:15:59 CET] <wm4_> libavcodec input should already be 1 frame per packet
[11:16:06 CET] <mateo`> speaking about that (i don't have the time to send a proper email atm), my next iteration on the patchset is to put all the jni stuff in lavc, avpriv -> ff, and drop the content uris stuff for now
[11:16:20 CET] <mateo`> wm4_: in the annex b form ?
[11:16:35 CET] <wm4_> no, the annex b conversion you still have to do
[11:16:39 CET] <wm4_> (usually)
[11:17:08 CET] <mateo`> then, this is what i'm doing with the parser in mediacodecdec_h264
[11:19:54 CET] <wm4_> is the parser maybe just a leftover that's not used anymore?
[11:23:03 CET] <mateo`> the parser is here to make the conversion if needed, (unless i'm guaranteed to always get one frame in the annex b format)
[11:24:25 CET] <wm4_> well looking a bit harder, the parser is initialized, but then never used and not even destroyed
[11:25:32 CET] <nevcairiel> parsers are not used for such conversion, you want the bitstream filter
[11:25:55 CET] <mateo`> mmm sorry, i was thinking about the bitstream filter the whole time
[11:26:10 CET] <mateo`> well the parser can be removed
[11:26:18 CET] <mateo`> it's clearly a left over
[11:31:11 CET] <mateo`> i'm asking to be sure i'm not going in the wrong direction, but are you ok that I put all the jni stuff in lavc, makes all this mess private
[11:31:20 CET] <mateo`> and see later what we do about the content uris ?
[11:32:34 CET] <wm4_> so mediacodec really wants you to extract the sps and pps manually?
[11:32:50 CET] <wm4_> mateo`: sounds good to me
[11:33:09 CET] <mateo`> yes it wants the sps / pps in the annex b format separately according to the document
[11:33:26 CET] <wm4_> keep it in a separate file, later we might access it from libavformat via #include "libavcodec/jni.c"
[11:33:29 CET] <mateo`> i might be possible to submit it as one chunk, i haven't tested that
[11:33:34 CET] <wm4_> nevcairiel: would that be reasonable?
[11:34:01 CET] <wm4_> I thought the annex b bsf already inserts the sps and pps in the stream
[11:34:55 CET] <wm4_> hm
[11:35:05 CET] <wm4_> or at least it overwites avctx->extradata with it
[11:36:11 CET] <wm4_> it might be doing both
[11:38:26 CET] <nevcairiel> it does both
[11:38:53 CET] <nevcairiel> unless you set the option for it not to
[11:39:18 CET] <wm4_> I don't really get the point of annex b extradata though, it's redundant?
[11:39:28 CET] <nevcairiel> kinda yes
[11:39:29 CET] <wm4_> (by design)
[11:39:39 CET] <nevcairiel> but some decoders like to initialize before getting bitstream
[11:39:57 CET] <nevcairiel> but i think mediacodec should work with inband annexb
[11:40:12 CET] <BtbN> Hm, I realy wonder weather I should add that CUDA Input-Frame thing from libav nvenc. I never heard of anyone asking for that, and I'm not a fan of AV_PIX_FMT_CUDA.
[11:40:36 CET] <BtbN> Also, I'd have to put up quite some effort to even be able to test it.
[11:41:01 CET] <nevcairiel> they also added a avfilter which can simply upload and create cuda frames for you, does that not work
[11:41:13 CET] <BtbN> Sure, but... why?
[11:41:18 CET] <nevcairiel> for testing
[11:41:18 CET] <nevcairiel> :D
[11:41:23 CET] <BtbN> That doesn't add any functionality
[11:41:42 CET] <nevcairiel> thats what i said, but presumably they have plans to add cuda processing or something
[11:42:02 CET] <wm4_> isn't it FAST
[11:42:14 CET] <wm4_> so you can avoid going over the CPU for some things
[11:42:18 CET] <BtbN> Why would it be faster if you manualy upload the frame to CUDA instead of letting NVENC do that?
[11:42:35 CET] <wm4_> well, if you have something that can decode to cuda surfaces
[11:42:42 CET] <nevcairiel> nvidia is the most painless when it comes to down/upload anyway
[11:42:43 CET] <wm4_> nvcuvid maybe? (lol)
[11:42:46 CET] <mateo`> wm4_, nevcairiel: i'll be off irc / ml for the next few days, the updated patchset can be expected for monday
[11:42:55 CET] <nevcairiel> wm4_: in fact it does =p
[11:43:20 CET] <nevcairiel> but nvcuvid is kinda dead, they havent worked on it in ages and it accumulated a few bugs
[11:43:57 CET] <wm4_> mateo`: ok... I'm still not sure if I understand the complex dataflow interaction with mediacodec, I guess I'll delay that until the new patch
[11:44:21 CET] <BtbN> The only thing where it'd be interesting with is NvFBC, which grabs the framebuffer right on the Nvidia GPU, so you can encode it without it ever hitting the system ram
[11:44:33 CET] <BtbN> But the NvFBC is under NDA
[11:44:37 CET] <BtbN> +API
[11:45:04 CET] <nevcairiel> reverse engineer it, if you didnt sign anything, you also didnt violate it
[11:45:06 CET] <BtbN> And it gives you D3D Surfaces instead of CUDA
[11:45:18 CET] <BtbN> I already did, it leaked several times
[11:45:30 CET] <BtbN> no need to reverse it, they just included the full SDK in some drivers accidentialy
[11:45:35 CET] <kierank> Can we get rid of this http server task for gsoc
[11:45:36 CET] <nevcairiel> the d3d11 screen grabbing works in similar ways though
[11:45:57 CET] <BtbN> The Win10-Exclusive DesktopDup thing?
[11:45:59 CET] <BtbN> Yeah, it's the same
[11:46:07 CET] <nevcairiel> its 8 upwards, not 10 only
[11:46:31 CET] <nevcairiel> and that API isnt secret =p
[11:46:47 CET] <nevcairiel> and relatively easy to use, as surprising as that sounds
[11:47:47 CET] <nevcairiel> 200 odd lines with boilerplate overhead
[11:49:13 CET] <nevcairiel> if mingw wouldnt suck so bad with d3d11 apis, i might even provide one for ffmpeg just as a PoC and example for others to follow =p
[11:50:29 CET] <wm4_> what's even the point of NDA'd APIs
[12:01:24 CET] <BtbN> So people pay you for the SDK.
[12:02:41 CET] <BtbN> Just went through all the changes the libav nvenc encoder ever had, and they all don't apply to the ffmpeg implementation. The CUDA frame input thing is the only actualy new feature, and I'm not sure how usefull it is.
[12:03:32 CET] <BtbN> Well, and there is https://git.libav.org/?p=libav.git;a=commitdiff;h=1520c6ff05d835da4b793318fc88bbbc129c86a1 which I'm not sure about, is that usefull? Would be trivial to add
[12:06:57 CET] <BtbN> I'm also not a fan of linking to the actual CUDA SDK. That thing is a mess
[12:07:31 CET] <BtbN> OpenCL seems like a much more reasonable choice for ffmpeg, but there is no interop aparently.
[12:08:24 CET] <wm4_> maybe there's opencl and cuda interop?
[12:08:31 CET] <wm4_> or opencl/opengl and opengl/cuda interop
[12:08:46 CET] <wm4_> why do I feel like I'm trolling
[12:10:47 CET] <BtbN> I'm also still amazed by that Nvidia-Hack-Patch they cassualy include in ther "How to NVENC with ffmpeg" guide PDF.
[12:10:52 CET] <BtbN> +i
[12:11:06 CET] <atomnuker> there's already interops between vaapi and vdpau and people use them
[12:11:21 CET] <wm4_> atomnuker: these are just emulation layers
[12:11:42 CET] <wm4_> not passing hardware surfaces from one API to another
[12:46:33 CET] <nevcairiel> BtbN: the cbp thing should be in our nvenc, i think i ported that one over since its largely independent of the nvenc implementation
[13:07:23 CET] <ethe> Did I send my patch correctly? (the one about jack) I've never sent a patch using git send-mail before, and I just want to make sure I did it right
[13:26:21 CET] <nevcairiel> didnt try applying it, but it looks ok on a quick glance
[13:48:17 CET] <BBB> whts the status of the automatic bitstream filters?
[13:50:54 CET] <nevcairiel> done and done?
[13:51:13 CET] <BBB> ah good
[13:51:32 CET] <wm4_> so where are we with m:n decoding
[13:51:49 CET] <J_Darnley> Is that some spam that slipped through on -cvslog?  The no subject email?
[13:53:03 CET] <wm4_> I see 3 choices: 1. just do what the audio API does (partial packet consumption), 2. add something that amounts to the same thing, but is on the granularity of not accepting input packets, so the user has to repeat them (like setting a flag in got_frame), 3. completely new API with separate packet input/frame output functions
[13:53:55 CET] <nevcairiel> dont think partial consumption is good or  required, you would only consume a frame or not anyway
[13:54:38 CET] <nevcairiel> a clean new api is probably best, but also the most involved to design
[13:54:42 CET] <wm4_> partial consumption would simply cover this case, and it would be equal to the audio API
[13:54:59 CET] <wm4_> but I think partial consumption is fragile, and decoders will for example not "consume" padding garbage
[13:56:10 CET] <alexyecu> Hi everybody. Here is a question about building an ffmpeg 2.0 without optimization under Win x64. Looks like this does not work. Possibly here is the problem: http://pastebin.com/gBAK3PTd
[13:59:51 CET] <michaelni> ethe, it applied cleanly but it disables jack here (see mail)
[14:02:01 CET] <nevcairiel> alexyecu: this is a known limitation, ffmpeg requires the compiler to still perform dead code elimination even when optimizations are disabled, if it doesnt then you cannot build like that
[14:07:13 CET] <alexyecu> nevcairiel, as I understand, It`s impossible to use debug in Visual Studio with current code. But the second variant (from the past) makes this possible for all compilers. So, why not to use it?
[14:07:51 CET] <nevcairiel> because its arguably uglier and it was decided a long time ago to use the current form
[14:08:23 CET] <nevcairiel> and if you want to develop with visual studio, i would recommend to temporarily disable optimizations in the files you are working on using a compiler pragma
[14:08:25 CET] <nevcairiel> works wonder for me
[14:08:59 CET] <ethe> michaelni right. I'm so stumped for that configure script. I guess I'm going to have to get a VM
[14:19:48 CET] <alexyecu> nevcairiel, but there are about 30 files using pasted construction, temporary disabling of optimizatiom looks like not very good idea. BTW, that`s not me, but my colleague works with current code, but I decided to ask here about his problem.
[14:20:34 CET] <kierank> http://obe.tv/obe-news/item/27-accelerating-the-use-of-vc-2-hq-for-software-based-light-video-compression
[14:20:59 CET] <kierank> blah blah marketing
[14:21:01 CET] <nevcairiel> alexyecu: i said you should disable it for the code in question you are working on, not everywhere
[14:23:11 CET] <wm4_> kierank: nice
[15:01:38 CET] <ethe> how can I print the values of stuff like enabled jack_indev in the configure script for debugging? I tried: echo $(enabled jack_indev) but that didn't seem to output anything
[15:15:49 CET] <J_Darnley> ethe: you can run it in the shell like bash -x configure
[15:15:56 CET] <J_Darnley> but that might be a little too verbose
[15:18:19 CET] <BBB> maybe bsf api should be rewritten so it consumes/outputs packets instead of what it does now?
[15:18:26 CET] <BBB> nice refcounting etc
[15:18:59 CET] <wm4> sounds like a nice idea
[15:22:54 CET] <durandal_1707> evilril plan is that already
[15:26:55 CET] <jamrial> speaking of bsf, a gsoc project could be adding some or the missing ones, like latm to asc
[15:27:36 CET] <jamrial> there's a feature request ticket about it, even
[15:28:04 CET] <ubitux> BBB: do you remember when you worked on porting the png paeth prediction asm?
[15:28:11 CET] <BBB> nope
[15:28:19 CET] <ubitux> :D
[15:28:25 CET] <BBB> I can try to help anyway
[15:28:28 CET] <BBB> what did I do wrong?
[15:28:44 CET] <BBB> durandal_1707: oh cool ok then I wont have to
[15:28:46 CET] <BBB> thanks elenril
[15:28:46 CET] <ubitux> oh probably nothing, i'm just wondering how efficient it could actually be
[15:29:03 CET] <ubitux> since every pixel seems to depend on the previous or something
[15:29:05 CET] <BBB> some of it was written by loren and is inherently scalar
[15:29:25 CET] <BBB> so its just abusing the fact that loren > compiler
[15:29:28 CET] <ubitux> and code is hard to follow (mainly because of the dst pointer hacks)
[15:42:30 CET] <wm4> so ffmpeg doesn't support opus gapless playback from .opus (ogg)
[15:43:09 CET] <wm4> hm according to the code it adds end trimming but none on the start?
[15:48:36 CET] <cone-088> ffmpeg 03Michael Niedermayer 07master:7ac962af38f0: avformat/avienc: Store pal8 palette
[15:56:57 CET] <kierank> can we remove this http server crap
[15:57:36 CET] <wm4> +1
[15:59:01 CET] <nevcairiel> i dont see that anymore
[15:59:06 CET] <nevcairiel> unless we're talking about other things
[15:59:37 CET] <kierank> I saw it this morning
[16:00:11 CET] <kierank> maybe that was an old page
[16:17:41 CET] <wm4> ah wtf, ffprobe.c does partial video frame decoding, while ffmpeg.c does not
[16:17:53 CET] <JEEB> funky
[16:18:37 CET] <wm4> ffprobe does partial decoding even for subtitles
[16:19:05 CET] <wm4> oh well ffmpeg.c also does
[16:22:14 CET] <wm4> wtf, avconv.c also does for video
[16:22:16 CET] <BBB> partial decoding
[16:22:18 CET] <BBB> what is that
[16:22:24 CET] <nevcairiel> consuming half a packet
[16:22:30 CET] <wm4> maybe a better term is partial packet reading
[16:22:46 CET] <wm4> so the only thing which doesn't do this is ffmpeg.c with video
[16:23:05 CET] <wm4> does that imply libav decoders return correct values, while ffmpeg's sometimes do not?
[16:23:43 CET] <nevcairiel> no it just means that it would bug out with some formats on libav =p
[16:24:48 CET] <BBB> michaelni: how do I disable the non-monotonous timestamp check in ffmpeg.c?
[16:24:56 CET] <BBB> michaelni: (from libavformat)
[16:25:22 CET] <BBB> michaelni: its triggering in a way that is not actually buggy (two subsequent write_interleaved with same pts, but only the second one gets past my bitstream filter)
[16:25:54 CET] <BBB> rcombs: actually, this is a auto-bsf bug
[16:26:07 CET] <BBB> rcombs: the auto-bsfs trigger that warning but manual bsfs don't
[16:29:05 CET] <wm4> interlaced HEVC produces two frames, right? why doesn't the parser just separate them?
[16:31:42 CET] <nevcairiel> on decoding thats what happens
[16:31:58 CET] <nevcairiel> the problem is with encoding, where one input frame would produce two packets
[16:33:10 CET] <wm4> wouldn't it just produce 2 concatenated packets?
[16:33:14 CET] <nevcairiel> interlaced in hevc is nothing special, just encoding two half-height frames individually and a few bits of metadata
[16:33:34 CET] <nevcairiel> wm4: then timestamps would be screwed up, the big magic of interlaced is that its temporally distinct points
[16:34:04 CET] <wm4> but that's already done for interlaced in general
[16:34:06 CET] <nevcairiel> so if oyu want to encode proper hevc interlaced, you need 1:2 api =p
[16:37:31 CET] <michaelni> BBB, AVFMT_TS_NONSTRICT may work but may or may not be what you are searching for
[16:38:40 CET] <michaelni> if its not container specific then the check possibly would need to be extended to allow whatever allows it
[16:41:08 CET] <JEEB> hmm, was there anything special regarding writing signed integers? avio_wb32 just fine?
[17:04:42 CET] <BBB> michaelni: see patch on ML
[17:05:07 CET] <BBB> michaelni: I really think ffmpeg.cs check is broken and should disappear or only enabled when specifically asked
[17:08:13 CET] <kierank> avdev is going down for a week
[17:08:34 CET] <BBB> kierank: tnx for mentioning
[17:09:01 CET] <ubitux> hey BBB, would you know why? https://twitter.com/tusbar/status/700709620659068928
[17:09:23 CET] <BBB> nope :-p
[17:09:42 CET] <ubitux> the nda is strong with this one
[17:09:46 CET] <ubitux> okay :)
[17:10:40 CET] <BBB> nda?
[17:10:43 CET] <BBB> I dont work for youtube
[17:10:52 CET] <BBB> I dont know anything
[17:10:53 CET] <ubitux> you were close, no?
[17:11:05 CET] <ubitux> anyway just a jk :)
[17:11:09 CET] <BBB> team was in chrome
[17:11:23 CET] <BBB> I would hang out every once in a while, but otherwise not really, no
[17:16:52 CET] <BtbN> I'd guess they make those IDs in a way so they are able to compensate for a typo?
[17:17:26 CET] <wm4> a typo for the last character?
[17:18:03 CET] <BBB> michaelni: I guess what Im looking for is some way to say I did not use these input packets, or alternatively some way to let the muxer auto-select bsfs (rcombs hi) but be able to run the bsfs manually so I know whether it caused a pkt skip or not
[17:18:38 CET] <BBB> (pkt skip happens when merging two frames into one superframe)
[17:21:05 CET] <rcombs> BBB: if you manually insert a BSF, lavf won't
[17:21:30 CET] <BBB> it works fine with manual insertion
[17:21:41 CET] <BBB> auto-insertion causes the non-monotonous pts errors
[17:21:53 CET] <BBB> and id like that warning to go away with auto-insertion
[17:22:08 CET] <BBB> because the warning is full of bullshit
[17:22:18 CET] <BBB> there is no pts error, its just that ffmpeg.c wasnt aware of it
[17:27:20 CET] <JEEB> ok, so looking at some fragmented isobmff that lavf writes
[17:28:00 CET] <JEEB> would implementing trun v1 semantics with negative composition time offsets for b-picture delay sound like a bad idea to people?
[17:28:21 CET] Action: JEEB is currently looking at how much of a PITA it would be
[17:34:44 CET] <nevcairiel> BBB: the warning kinda makes sense, because the auto-bsf happens after ffmpeg.c code, and for ffmpeg you are sending two or more frames with the sme timestamp
[17:35:02 CET] <nevcairiel> while manual bsf happens inside ffmpeg.c
[17:35:20 CET] <nevcairiel> not sure how to make it happier though
[17:36:45 CET] <BBB> right, thats exactly my problem
[17:36:53 CET] <BBB> I understand why ffmpeg.c currently emits the warning
[17:37:03 CET] <BBB> but the warning is bollocks nonetheless
[17:37:14 CET] <BBB> so Id like some way to prevent triggering that warning in such cases
[17:37:28 CET] <BBB> so users dont see warnings and freak out or get slightly adjusted timestamps for no reason whatsoever
[17:42:34 CET] <michaelni> IIUC, somethng link AVFMT_TS_NONSTRICT could be added at codec level or simply a codec_id == AV_CODEC_ID_VP9 check in ffmpeg
[17:44:51 CET] <Timothy_Gu> ethe: enabled jack_indev && echo enabled || echo disabled
[17:45:17 CET] <ethe> thanks. (i got it now anyways though)
[17:45:19 CET] <Timothy_Gu> enabled doesn't print anything so $() doesn't work
[17:45:25 CET] <Timothy_Gu> ok
[17:45:31 CET] <ethe> sem_timed was the problem
[17:46:15 CET] <ethe> sem_timewait*, it wasnt being checked, im just about to revert to a clean tree to see if it worked before (because it doesnt even look like it should have worked before on any OS)
[17:58:50 CET] <BBB> michaelni: it only happens for vp9 when you use -c:v copy
[17:58:57 CET] <BBB> michaelni: during regular encoding this doesnt occur
[18:03:28 CET] <BBB> michaelni: maybe a check for vp9 && codec==copy would make sense
[18:04:58 CET] <BBB> michaelni: although Im not quite familiar with how ffmpeg.c works so some sample code would be helpful
[18:08:00 CET] <michaelni> BBB to detect copy you should be able to use the stream_copy field or encoding_needed field
[18:11:31 CET] <michaelni> detecting vp9 should be trivial, theres already code there that checks codec_type so the check doesnt trgger for odd streams, the same context should have a codec_id ...
[18:29:34 CET] <ethe> michaelni damn. sorry, I messed up git send-email
[18:48:03 CET] <cehoyos> BBB: Did it work without braces? (Why?)
[18:48:25 CET] <BBB> I only tested ivf, so no idea
[18:48:32 CET] <cehoyos> Ok, thanks
[18:48:34 CET] <BBB> I agree there should be braces regardless
[18:49:10 CET] <cehoyos> I don't know what the compiler should do and I was unable to find an explanation online, so I wondered if you know...
[18:49:34 CET] <cehoyos> I still believe it cannot work though...
[18:50:13 CET] <BBB> it probably doesnt then
[18:51:37 CET] <nevcairiel> gcc warns about such constructs
[18:51:52 CET] <cehoyos> I thought so but didn't test
[18:53:22 CET] <nevcairiel> technically both interpretations are valid according to the strictest language grammer, but i believe its always mapped to the inner if
[18:58:50 CET] <cehoyos> Thank you
[19:01:59 CET] <wm4> cehoyos: so are you ok with the videotoolbox encoder configure change?
[20:32:07 CET] <BBB> michaelni: just tested that ffmpeg.c change, and that makes it worse, now Im triggering compute_muxer_pkt_fields errors
[20:32:18 CET] <BBB> [ivf @ 0x7fa1cb00f600] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 33 >= 33
[20:32:54 CET] <cone-088> ffmpeg 03James Almer 07master:76af0c78772f: checkasm: fix dependencies for vf_blend tests
[20:33:13 CET] <BBB> Ill test if applying auto-bsfs before compute_muxer_pkt_fields fixes that
[20:33:31 CET] <BBB> yes it seems it does
[20:58:49 CET] <cehoyos> wm4: I had not seen it yet, where can I find it?
[20:59:06 CET] <cehoyos> But if it does not use auto-detection this leads to unavoidable bitrot;-(
[21:02:01 CET] <ethe> what's the practise for amending a patch? do resend the whole patch, send a patch for the patch? it's only a couple lines which have to be fixed
[21:04:53 CET] <cone-088> ffmpeg 03Carl Eugen Hoyos 07master:84d7933e3b9c: lavc/libvpx: Fix high-bitdepth pix_fmts on big endian.
[21:05:14 CET] <jamrial> ethe: resend the whole patch as a reply to the previous version
[21:10:51 CET] <ethe> are all the indevs on by default?
[21:11:33 CET] <wm4> cehoyos: he resent the patch (v6)
[21:12:28 CET] <cone-088> ffmpeg 03Carl Eugen Hoyos 07master:432be6362c31: lavc/libvpx: Fix support for RGB colorspace.
[21:12:29 CET] <cone-088> ffmpeg 03Carl Eugen Hoyos 07master:73781741b7bf: lavc/libvpx: Reindent after last commit.
[21:27:15 CET] <cehoyos> wm4: He added the autodetection, I believe this is a good idea
[21:30:11 CET] <wm4> then I'll apply the patch tomorrow or so
[23:09:43 CET] <cone-088> ffmpeg 03Marton Balint 07master:51afd9f4e1f7: avformat/dvbtxt: add raw demuxer for dvb teletext probing
[23:09:44 CET] <cone-088> ffmpeg 03Marton Balint 07master:6c905dd3c24a: avcodec/libzvbi-teletextdec: use common functions for matching data_unit_id and data_identifier
[23:09:45 CET] <cone-088> ffmpeg 03Marton Balint 07master:308ac2f7e204: ffmpeg: init input streams before opening encoders
[23:26:12 CET] <nevcairiel> michaelni: your freebsd systems are out of space (ie.  x86_32-debian-kfreebsd-gcc-4.4-cpuflags-sse3 and more)
[00:00:00 CET] --- Sat Feb 20 2016