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

[burek]

[00:32:00 CEST] <cone-446> ffmpeg 03Vivekanand 07master:b092ee701f4d: avformat/allformats: Making av_register_all() thread-safe.
[00:55:29 CEST] <cone-446> ffmpeg 03Michael Niedermayer 07master:abc957e896be: avfilter/af_amix: dont fail if there are no samples in output_frame()
[01:21:28 CEST] <BBB> huh?
[01:21:32 CEST] <BBB> why was the bt2020 patch committed?
[01:22:12 CEST] <BBB> ohwell
[02:00:21 CEST] <durandal_1707> it's wrong?
[02:02:55 CEST] <BBB> it had outstanding comments from an earlier review, didnt it?
[02:03:02 CEST] <BBB> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-March/192200.html
[02:03:05 CEST] <BBB> where those addressed?
[02:03:52 CEST] <BBB> hm, I think only 1/4 and 2/4 were applied, not 3/4 and 4/4
[02:03:54 CEST] <BBB> nevermind then
[02:04:36 CEST] <durandal_1707> michaelni likes gpl, that filter should be gone
[02:05:52 CEST] <michaelni> BBB, yes, i skiped all that had comments, or at least i intended to
[02:10:17 CEST] <durandal_1707> michaelni: how should we proceed with sheervideo, it have bunch of formats with big static tables, perhaps init_vlc can compress them?
[02:11:59 CEST] <michaelni> yes, smaller tables should be better
[02:13:48 CEST] <michaelni> anything i should help with on that ?
[02:14:05 CEST] <michaelni> i thought you wanted to do it as you asked about how it can be done ...
[02:15:20 CEST] Action: michaelni must help with fixing trac regressions, it seems there are a bunch
[02:15:43 CEST] <michaelni> 3.1 should not have that many regressions
[02:19:00 CEST] <cone-446> ffmpeg 03Michael Niedermayer 07master:5a8b41b4a76f: avformat/movenc: Skip unsupported video tracks in timecode generation
[02:35:56 CEST] <cone-446> ffmpeg 03Michael Niedermayer 07master:bacc4b6e8173: avcodec/wmalosslessdec: Use unsigned operations for overflowing cases
[05:33:11 CEST] <cone-446> ffmpeg 03Michael Niedermayer 07master:b5bc436ebc57: avformat/matroskadec: Fix rounding error with codec_delay
[05:53:20 CEST] <CoJaBo> michaelni: any progress on the bmp bug by any chance? :/
[10:28:17 CEST] <andrey_turkin_> BtbN: M4000 seems to be working fine with yuv420p so simple caps check is not an option
[10:33:48 CEST] <durandal_1707> michaelni: could you attempt to make tables for sheervideo smaller? Just for one format, document algo used so I can convert rest?
[10:50:17 CEST] <BtbN> andrey_turkin_, the hell. So this is some bug only some cards have?
[10:50:44 CEST] <nevcairiel> might as well be a driver thing
[10:50:45 CEST] <andrey_turkin_> chances are all Maxwell2 GeForces, maybe depending on a driver version
[10:51:05 CEST] <andrey_turkin_> I also saw race condition inside nvenc but only Quadro
[10:51:24 CEST] <andrey_turkin_> it seems Quadro and GeForce drivers are sufficiently different 
[10:52:34 CEST] <andrey_turkin_> Is here anyone else with Maxwell/Maxwell2 hardware who can check that?
[11:13:52 CEST] <BtbN> philipl, ^?
[11:14:29 CEST] <BtbN> andrey_turkin_, well, I'm in front of a GT940 right now, definitely a Maxwell card.
[11:14:34 CEST] <BtbN> But they stripped out the video unit...
[11:16:07 CEST] <andrey_turkin_> huh? nvenc doesn't work on that?
[11:16:15 CEST] <BtbN> No nvenc, no vdpau.
[11:16:50 CEST] <BtbN> It's a laptop with Optimus, so I guess the reasoning was "the intel card can already do that, so off with that"
[11:16:53 CEST] <nevcairiel> you mean GT940M, and its really up to the OEM that uses these which features to enable
[11:16:57 CEST] <andrey_turkin_> oh wow. they all suck. Nvidia, Intel, who else does that?
[11:17:22 CEST] <BtbN> And yes, the Intel card in this can indeed to decoding/encoding just fine.
[11:17:23 CEST] <andrey_turkin_> ah, Optimus. They are kinda strange
[11:17:31 CEST] <BtbN> Still annoying if you want to test nvenc
[11:18:17 CEST] <andrey_turkin_> then it actually makes sense to disable nvenc since Intel's GPU is always on and can do everything "usual user" wants
[11:19:10 CEST] <nevcairiel> are you sure its just not reachable because optimus sucks? :)
[11:20:18 CEST] <BtbN> I can reach the nvidia GPU and run CUDA stuff just fine
[11:20:35 CEST] <BtbN> but initializing anything using the video engine, nvenc, cuvid or vdpau, just plain fails.
[11:37:07 CEST] <BtbN> andrey_turkin_, cuvid only outputs exactly one width/height. And it seems to be the real video width/height, so for 1920x1088, it's 1920x1080
[11:38:22 CEST] <andrey_turkin_> did you tried weird input dimensions?
[11:39:23 CEST] <BtbN> I don't have any samples for that.
[11:40:09 CEST] <andrey_turkin_> you can make them easily
[11:40:36 CEST] <andrey_turkin_> 'cause nvcuvid.h header seems to contradict you
[11:41:13 CEST] <andrey_turkin_> of course the comments there might be wrong but it best to doublecheck
[11:42:10 CEST] <BtbN> what do you mean?
[11:42:11 CEST] <andrey_turkin_> E.g. generate white field 323x245 with 1 pixel border and encode that as hevc/h264
[11:42:29 CEST] <andrey_turkin_> see CUVIDEOFORMAT.display_area comments
[11:44:50 CEST] <andrey_turkin_> and if the comment is indeed wrong and your understanding of coded_width/coded_height is correct then it deserves a comment to explicitly state that
[11:45:17 CEST] <BtbN> coded_height should be 1088 to my understanding of it
[11:49:40 CEST] <andrey_turkin_> I don't think your patch will handle that correctly
[11:56:30 CEST] <nevcairiel> the comments in nvcuvid.h are correct
[11:56:35 CEST] <nevcairiel> thats how it behaves for me
[12:14:13 CEST] <nevcairiel> i should probably wait before sending a review mail instead of fiding new things to comment on later, but what can you do
[12:37:56 CEST] <BtbN> andrey_turkin_, regarding the width/height align, i belive 16 is correct
[12:38:35 CEST] <BtbN> If both width/height are 16 byte aligned, the resulting buffer size (width * height) will be 32 byte aligned.
[12:38:52 CEST] <nevcairiel> those w/h values should be aligned already anyway, as h264 and hevc require that
[12:39:11 CEST] <BtbN> yeah, but not by 32
[12:40:33 CEST] <andrey_turkin_> ulTargetWidth/Height doesn't have to be aligned
[12:40:45 CEST] <BtbN> They aren't.
[12:40:56 CEST] <BtbN> hwframe_ctx->width/height are though
[12:40:56 CEST] <andrey_turkin_> and CUDA frame dimensions are calculated from those
[12:41:27 CEST] <BtbN> The CUDA frame comes out with whatever pitch cuvid feels like anyway
[12:41:37 CEST] <nevcairiel> if ululTargetWidth/Height are not aligned, then your cuvid decoder behaves quite differently then mine =p
[12:41:59 CEST] <BtbN> aren't those the fields where the actual frame sizes are expected?
[12:42:05 CEST] <BtbN> Like, 1080 instead of 1088?
[12:42:27 CEST] <nevcairiel> the "actual frame size" is 1088, cropping info is just metadata afterwards, the decoder doesnt care
[12:42:35 CEST] <nevcairiel> you can adjust targetwidth/height if you want to scale
[12:42:48 CEST] <nevcairiel> ie. you can actually tell it to scale in the decoding process
[12:43:06 CEST] <nevcairiel> but i wouldnt recommend that, its of questionable quality
[12:43:08 CEST] <andrey_turkin_> ah, so if we don't want to scale there then targetwidth has to be equal to coded_width
[12:43:31 CEST] <BtbN> There is no metadata about that after cuvid is done with the frame. So the output AVFrame should be 1920x1080.
[12:43:39 CEST] <BtbN> Or where does it store that?
[12:43:56 CEST] <andrey_turkin_> but you already know which picture size should be from display_area
[12:44:05 CEST] <nevcairiel> the cuvid decoder doesnt care, it has no concept of cropping
[12:44:17 CEST] <nevcairiel> you just have to remember from CUVIDEOFORMAT
[12:44:46 CEST] <BtbN> So I set avctx->width/height to the display area size, and some other parts just ignore the additional lines?
[12:44:58 CEST] <BtbN> And set target width/height to the coded_width/height
[12:45:04 CEST] <nevcairiel> pretty much
[12:45:15 CEST] <nevcairiel> note that avctx also has a coded_w/h field, you should set those as well
[12:47:20 CEST] <BtbN> https://github.com/BtbN/FFmpeg/blob/cuvid/libavcodec/cuvid.c#L74 that's how it is now, should be correct so far.
[12:47:55 CEST] <BtbN> I'm not exactly sure under what circumstances left/top would ever be non-zero. In that cases stuff would fail, as there is no such field in avctx.
[12:48:03 CEST] <andrey_turkin_> from NVENC docs: The input buffer width and height should be 32-aligned.
[12:48:09 CEST] <nevcairiel> h264 supports such cropping values
[12:48:26 CEST] <nevcairiel> unless you handle them properly elsewhere, you should probably just stick to pure right/bottom
[12:48:37 CEST] <nevcairiel> even if not entirely correct
[12:48:44 CEST] <nevcairiel> there is one fate sample with such cropping info
[12:49:07 CEST] <andrey_turkin_> you can it theory shift data pointers inside buffers, like crop does
[12:49:07 CEST] <BtbN> Iirc the h264 software decoder also doesn't support them
[12:49:22 CEST] <nevcairiel> it does if you set a flag to allow un-aligned data pointers
[12:49:32 CEST] <andrey_turkin_> but then they are going to be misaligned
[12:49:40 CEST] <BtbN> There also is an issue with the built-in deinterlacing.
[12:49:51 CEST] <BtbN> I think I have to duplicate frames?
[12:50:15 CEST] <nevcairiel> its really not something a decoder is designed to do properly
[12:50:22 CEST] <nevcairiel> since that w ould require 1:2 output pattern
[12:50:25 CEST] <nevcairiel> which we cant really do
[12:50:32 CEST] <nevcairiel> (not yet anyway)
[12:50:48 CEST] <BtbN> It would result in an infinitly growing fifo
[12:51:08 CEST] <andrey_turkin_> new decoding api can, right? not sure if hw accel stuff would stand it the way
[12:52:01 CEST] <nevcairiel> the new api can, but we also still support the old API
[12:52:04 CEST] <andrey_turkin_> BtbN: I'd rather see 32-pixel alignment just in case (to be in compliance with nvenc). It doesn't hurt to overalign a bit
[12:52:24 CEST] <BtbN> andrey_turkin_, for which fields does nvenc say that?
[12:52:39 CEST] <andrey_turkin_> I thought old api entrypointes automatically use new api from codec if old is not available
[12:52:57 CEST] <andrey_turkin_> [13:48] <andrey_turkin_> from NVENC docs: The input buffer width and height should be 32-aligned.
[12:53:07 CEST] <BtbN> The values I align for 16 are only used by the hwcontext stuff, to allocate the CUDA buffers.
[12:53:11 CEST] <BtbN> It's not used anywhere else.
[12:53:25 CEST] <andrey_turkin_> those same buffers are going to go into nvenc
[12:53:42 CEST] <andrey_turkin_> which will see their internal layout
[12:53:47 CEST] <BtbN> It would only result in emtpy data at the end
[12:54:11 CEST] <BtbN> Does it refer to the pitch/linesize? It wants that to be 32 byte aligned?
[12:54:42 CEST] <andrey_turkin_> it says both height and width (I guess same as linesize) have to be aligned
[12:55:16 CEST] <andrey_turkin_> maybe it is just for some corner-cases like interlaced HEVC but it really doesn't hurt to overalign a bit. Memory waste is minimal
[12:55:37 CEST] <BtbN> Those fields are not the place to do that though.
[12:56:19 CEST] <andrey_turkin_> hwframe_ctx->width = FFALIGN(avctx->coded_width, 16);
[12:56:34 CEST] <BtbN> That's only for the hwframes context
[12:56:38 CEST] <BtbN> nvenc never sees those values
[12:56:46 CEST] <andrey_turkin_> how do you figure that?
[12:57:21 CEST] <BtbN> They are purely used for the hwcontext_cuda, to allocate a sufficiently large buffer.
[12:59:26 CEST] <BtbN> This would also need fixing in hwupload_cuda, btw. That's where the 16 comes from.
[12:59:30 CEST] <andrey_turkin_> so... you allocate a cuda frame from hwcontext, you copy data from another (cuvid-owned) cuda frame, and then you send that allocated frame out to the world. In case where there are no filters between cuvid and nvenc, nvenc is going to see same frame you just allocated 
[13:00:05 CEST] <BtbN> Yes, so it sees the width/height field of the frame. Not the one of the hwcontext.
[13:00:14 CEST] <BtbN> And 32 byte aligining the width/height of the frame itself seems wrong to me.
[13:00:57 CEST] <andrey_turkin_> it is nvenc we are talking about. It works closely with cuda to get actual parameters of the buffer
[13:01:01 CEST] <nevcairiel> The HEVC DXVA specification asks for aligning the GPU surfaces by 128, so take that =p
[13:01:16 CEST] <andrey_turkin_> ouch
[13:01:21 CEST] <BtbN> yes, for the total buffer size
[13:01:26 CEST] <BtbN> but for the width/height of the frames?
[13:01:27 CEST] <nevcairiel> no, for the stride
[13:01:47 CEST] <BtbN> ah, yes. The pitch i get from cuvid is something ridiculous like 4096
[13:01:50 CEST] <nevcairiel> and probably height as well
[13:02:06 CEST] <nevcairiel> power of two is nice for GPUs :)
[13:02:44 CEST] <nevcairiel> for HEVC its about some coding tools, so it can choose to use a bigger block even at the border of the image without needing to allocate new frames
[13:02:47 CEST] <BtbN> I guess hwcontext_cuda needs some patching
[13:02:53 CEST] <BtbN> it sets the linesize to width, exactly
[13:03:33 CEST] <BtbN> ah, well. The hwctx width, so aligning that helps a bit there.
[13:05:29 CEST] <andrey_turkin_> now that I've reread programming guide, it only requires that for nvenc-allocated frames, not for externally mapped frmes
[13:05:46 CEST] <andrey_turkin_> I don't know if same requirement holds for those as well
[13:08:08 CEST] <BtbN> I'm thinking about dropping those checks in init_transcoding entirely, and replacing them with a if (ist->hwaccel_id != HWACCEL_CUVID) return 0;
[13:08:24 CEST] <BtbN> If the user configures an impossible graph, so let it explode.
[13:09:10 CEST] <andrey_turkin_> sounds about right to me
[13:09:35 CEST] <BtbN> maybe leaving in the check for the decoder to support CUDA output, that one makes sense
[13:24:01 CEST] <BtbN> Just noticed that stuff will horribly explode if someone tries to use multiple diffrent hwaccels at the same time
[13:25:15 CEST] <andrey_turkin_> nobody ever does that?
[13:25:38 CEST] <BtbN> Somebody could though. vaapi for one decode, cuvid for another.
[13:25:52 CEST] <BtbN> There is only one global hw_device_ctx, stuff would crash.
[13:26:12 CEST] <andrey_turkin_> one would really want to, since it is easier to just start 2 instances of ffmpeg
[13:26:49 CEST] <BtbN> Well, I'll at least prevent the crash, and print a somewhat sensible error message.
[13:30:21 CEST] <jkqxz> Yeah, I didn't try to support that case at all.  I don't think it's useful in ffmpeg, if you want to do ridiculous things like that you can use lav* directly.
[13:30:44 CEST] <BtbN> Yes, supporting it would be not worth it.
[13:30:56 CEST] <BtbN> But not crashing is a matter of if (hw_device_ctx->type != AV_HWDEVICE_TYPE_CUDA) {
[13:31:39 CEST] <jkqxz> (Also multiple devices of the same type don't work.  That's slightly less absurd, but still unlikely to be worth doing.)
[13:31:53 CEST] <BtbN> Multiple devices of the same type should work fine?
[13:34:14 CEST] <jkqxz> With different -hwaccel_device?  I didn't make that work for vaapi.
[13:37:43 CEST] <BtbN> They just all share the hw_device_ctx
[13:38:11 CEST] <BtbN> So yeah, multiple GPUs at the same time wouldn't work. I guess that's what you mean?
[13:38:12 CEST] <jkqxz> cuda makes that magically work across cards?  That's neat I guess.
[13:38:20 CEST] <jkqxz> Oh.  Yes, I did.
[13:38:38 CEST] <BtbN> Well, in a sense, cuda DOES make that magically work.
[13:38:47 CEST] <BtbN> With SLI, CUDA only sees one GPU.
[13:42:49 CEST] <andrey_turkin_> really? this sounds weird. Maybe with SLI, but several independent cards would have their own contexts
[13:43:02 CEST] <BtbN> Depends on the SLI mode, of course.
[13:43:10 CEST] <andrey_turkin_> well if there is no SLI
[13:43:16 CEST] <andrey_turkin_> say, just plain old 2x cards
[13:54:26 CEST] <BtbN> I think with current drivers you can still SLI-Combine them.
[13:54:35 CEST] <BtbN> But yes, you can configure them to appear as two independend GPUs.
[14:01:23 CEST] <BtbN> andrey_turkin_, context_create would indeed be nice. It's in 3 places now already, basically the same set of lines.
[14:01:37 CEST] <andrey_turkin_> right
[14:02:04 CEST] <andrey_turkin_> but this probably depends on whoever merges libav to ffmpeg
[14:02:49 CEST] <BtbN> Is anyone doing merges at the moment?
[14:03:31 CEST] <andrey_turkin_> I dunno. I think there were some talks about problematic commit or something
[14:03:50 CEST] <BtbN> Could allways just cherry-pick it, the merge would be a no-op then.
[14:05:03 CEST] <andrey_turkin_> Only if it stays exactly the same on ffmpeg side until related commit is merged in
[14:05:26 CEST] <BtbN> Even then
[14:05:33 CEST] <BtbN> The merge would just do nothing.
[14:05:34 CEST] <andrey_turkin_> altough it is not that hard piece of code to merge manually in any case
[14:06:10 CEST] <andrey_turkin_> I don't think it wouldn't do anything. Cherry-picks are not handled any differently by merge AFAIC
[14:06:34 CEST] <BtbN> The person merging would notice that it's already there, and no-op it.
[14:07:19 CEST] <andrey_turkin_> right. People are smarter than git
[14:07:32 CEST] <BtbN> nevcairiel, is display_aspect_ratio from CUVIDEOFORMAT the same as the sample_aspect_ratio in avctx?
[14:08:08 CEST] <andrey_turkin_> probably not
[14:08:27 CEST] <andrey_turkin_> DAR=PAR*SASR
[14:26:02 CEST] <BtbN> https://bpaste.net/show/649091c46ca5 so, like this?
[14:28:51 CEST] <andrey_turkin_> yes, except for y
[14:54:24 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07master:bfe945ac3a0c: avcodec/bmp_parser: Fix frame_start_found in cross frame cases
[14:54:24 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07master:250b620d296a: avcodec/bmp_parser: Fix remaining size
[14:54:24 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07master:37005e65eb17: avcodec/bmp_parser: reset state
[14:54:24 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07master:43a4276c6964: avcodec/bmp_parser: Check fsize
[15:18:36 CEST] <prelude2004c> andrey_turkin_ , good day sir.. any further recommendations to my issue.. i am thinking of having some build me the code in ffmpeg to capture the cc data and then pass it along to output .. where should this code go ? nvenc.c ? or somewhere else ?
[15:18:49 CEST] <prelude2004c> i do want to help with development of this stuff
[15:28:51 CEST] <andrey_turkin_> check my messages from Saturday
[15:30:27 CEST] <andrey_turkin_> http://ffmpeg.gusari.org/irclogs/2016/06/04/ffmpeg-devel.log.20160604  from 20:09
[15:38:05 CEST] <prelude2004c> ok so... we have to build the filters for " ffmpeg -i output.ts -filter_complex '[0:v]split=2[main][cc]; [main]fps=30,scale=w=iw/2:h=-1[main_out]; [main_out][cc]combine_a53' -c:v nvenc -a53cc 1 scaled.mpg " as the example right ?
[15:38:16 CEST] <prelude2004c> those filters would not work already would they?
[15:39:03 CEST] <andrey_turkin_> already? you mean in stock ffmpeg? no they wouldn't
[15:39:56 CEST] <prelude2004c> understood.. hum... based on your knowledge how long do you think it would take to implement such a filter ?
[15:40:20 CEST] <andrey_turkin_> uhm... check same irc log few lines up for my previous message
[15:41:56 CEST] <andrey_turkin_> idea here is to preserve captions in separate "stream" in filterchain, do all video processing in another stream and then put all captions data back, possibly concatenating data from several input frames into one output video frame
[15:42:10 CEST] <prelude2004c> hum... yup exactly...
[15:42:25 CEST] <prelude2004c> this other ffmpeg version supposed to have this function ? sorry a bit confused.. trying to wrap my head around it
[15:42:34 CEST] <andrey_turkin_> yes
[15:42:47 CEST] <prelude2004c> ok i will try with that filter
[15:43:04 CEST] <prelude2004c> then i have to have the DHE code ported again to this version :) 
[15:43:14 CEST] <prelude2004c> or maybe the code can be pulled out into the latest git if it works ?
[15:43:19 CEST] <andrey_turkin_> it's based on git head
[15:43:27 CEST] <andrey_turkin_> so DHE code should work
[15:43:36 CEST] <prelude2004c> ok going to put DHE code now to see
[15:43:41 CEST] <DHE> my code just fixes the mpegts demuxer
[15:44:28 CEST] <andrey_turkin_> not sure about pushing it to ffmpeg proper, at least not in its current state (altough it does help with one case but it si also extremely hackish)
[15:44:34 CEST] <prelude2004c> DHE code it worked :) btw, you guys are awesome if I forget to say it often :) 
[15:45:55 CEST] <prelude2004c> ok so i am compiling the a53 ffmpeg version... then i will try and use that filter above to see what happens... andrey_turkin, am i on the right track ?
[15:46:06 CEST] <andrey_turkin_> right
[15:46:09 CEST] <prelude2004c> that is what i decoded from the plain text you wrote :) 
[15:46:25 CEST] <andrey_turkin_> it did worked for me with 2x fps reduction but not with 4x
[15:46:46 CEST] <prelude2004c> ahh ok... well thats alright.. i only drop by half
[15:46:51 CEST] <andrey_turkin_> I'm guessing there is too much data to be fit into each frame in 4x case
[15:46:52 CEST] <prelude2004c> its mostly 60fps content going to 30fps
[15:47:07 CEST] <andrey_turkin_> btw does anybody know if avfilter currently supports subtitle/data streams?
[15:50:37 CEST] <prelude2004c> ${ffmpeg} -hwaccel vdpau -threads 1 -i "$stream" $mapping -r 30 -vf "field,setsar=1:1,setdar=16:9" -filter_complex '[0:v]split=2[main][cc]; [main]fps=30,scale=w=iw/2:h=-1[main_out]; [main_out][cc]combine_a53' -c:v nvenc -a53cc 1  ..... 
[15:50:45 CEST] <prelude2004c> unrecognized option a53cc
[15:51:01 CEST] <prelude2004c> ehh i didn't compile it in ? 
[15:51:02 CEST] <prelude2004c> maybe..
[15:52:28 CEST] <andrey_turkin_> probably
[15:52:42 CEST] <prelude2004c> i should not have to compile it in do i ?
[15:53:08 CEST] <prelude2004c> hum..
[15:53:51 CEST] <andrey_turkin_> are you sure you got a53 branch?
[15:54:08 CEST] <prelude2004c> ya pretty sure... well double checking of course but... i did from the link you gave me with git
[15:54:17 CEST] <prelude2004c> https://github.com/tea/FFmpeg/tree/a53
[15:59:59 CEST] <cone-433> ffmpeg 03Martin Vignali 07master:753088a2a4d1: avcodec/exr: fix layer detection
[16:00:00 CEST] <cone-433> ffmpeg 03Martin Vignali 07master:d24eb9a3c6cc: avcodec/exr: indent the if (layer_match) part
[16:00:01 CEST] <cone-433> ffmpeg 03Martin Vignali 07master:42297d8419cd: avcodec/exr: fix tile decoding when all channels doesnt have the same pixel type
[16:00:02 CEST] <cone-433> ffmpeg 03Martin Vignali 07master:16107aeaf31c: avcodec/exr: remove unneed scanline_size var
[16:00:03 CEST] <cone-433> ffmpeg 03Martin Vignali 07master:03152e74dfdc: avcodec/exr: improve pxr24 uncompress
[16:00:04 CEST] <cone-433> ffmpeg 03Martin Vignali 07master:df7cd4176a29: avcodec/exr: move channel_line_size to thread data
[16:00:05 CEST] <cone-433> ffmpeg 03Martin Vignali 07master:bc1f3dfaa34b: avcodec/exr: fix decoding of B44 exr when all channel doesnt have the same pixel type
[16:00:06 CEST] <cone-433> ffmpeg 03Martin Vignali 07master:9511a0895dda: avcodec/exr: indent b44 uncompress function
[16:07:07 CEST] <prelude2004c> going to try and move the code over to the existing version
[16:09:42 CEST] <prelude2004c> recompiling ..
[16:10:56 CEST] <prelude2004c> who wrote that? someone else or you did " andrey_turkin " ? 
[16:11:18 CEST] <andrey_turkin_> me
[16:12:40 CEST] <prelude2004c> hum.. /home/ffmpeg-zz-patch/libavfilter/allfilters.c:158: undefined reference to `ff_vf_combine_a53' 
[16:12:45 CEST] <prelude2004c> checking if i missed something
[16:16:22 CEST] <andrey_turkin_> you need to do reconfigure
[16:16:49 CEST] <andrey_turkin_> or maybe I screwed something up (it compiles for me though)
[16:17:05 CEST] <prelude2004c> ya ok i just did a make clean to see
[16:17:25 CEST] <andrey_turkin_> you need to reconfigure. It should've said so when you tried to do make
[16:17:44 CEST] <prelude2004c> didn't say anything really... but i am trying again.. :) 
[16:17:48 CEST] <andrey_turkin_> something like "allfilters.c is newer than config.h" or along those lines
[16:21:23 CEST] <prelude2004c> ok so migrating code to current version i had didn't work :) .. running it on the a53 branch
[16:23:40 CEST] <prelude2004c> weird same thing
[16:23:57 CEST] <prelude2004c> running with " ./configure --enable-gpl --enable-nonfree --enable-nvenc --enable-pthreads --enable-vdpau --enable-hwaccel=mpeg2_vdpau --enable-hwaccel=h264_vdpau --enable-hwaccel=mpeg4_vdpau --disable-inline-asm --enable-x11grab --enable-ffplay --enable-static --extra-cflags=-I/usr/local/cuda-7.5/include --enable-libfdk-aac --extra-cflags=-I/usr/include --extra-ldflags=-L/usr/lib " 
[16:24:08 CEST] <prelude2004c> i did the make clean , make -j 50 
[16:24:20 CEST] <prelude2004c> no errors.. but then gives me the Unrecognized option 'a53cc'.
[16:24:33 CEST] <prelude2004c> unless i am to use combined_a53cc or something 
[16:24:46 CEST] <prelude2004c> the naming was kept the same right?
[16:24:52 CEST] <andrey_turkin_> what does git show say?
[16:25:42 CEST] <prelude2004c> http://pastebin.com/raw/reaXBc6b
[16:25:53 CEST] <andrey_turkin_> yeah, that's not a53 branch
[16:26:27 CEST] <prelude2004c> wtf ?  i ran  git clone https://github.com/tea/FFmpeg.git ffmpeg-a53
[16:26:44 CEST] <andrey_turkin_> ah. See, here it would clone master branch
[16:26:54 CEST] <prelude2004c> ohhhhhhhhhhh
[16:26:57 CEST] <prelude2004c> :(
[16:27:08 CEST] <andrey_turkin_> just do git checkout a53
[16:27:16 CEST] <andrey_turkin_> reconfigure, rebuild, etc
[16:27:39 CEST] <prelude2004c> OMG.. i have a lot to learn
[16:27:49 CEST] <prelude2004c> i didn't even know those things existed :P haha
[16:32:57 CEST] <prelude2004c> andrew_turkin , so.... the closed caption is working it seems and does not pause as before... which is a good thing.. only problem now is.. the words are all still messed up
[16:33:12 CEST] <BtbN> I wonder if the cuvid decoder just completely kills that cc stuff
[16:33:23 CEST] <prelude2004c> check out " http://67.55.3.103/cbcvancouverhd1150vdpau/cbcvancouverhd1150vdpau.m3u8 "
[16:33:33 CEST] <BtbN> I don't see it exporting that kind of data
[16:33:43 CEST] <prelude2004c> i am using the vdpau decoder .. and when i don't push 30fps its normal
[16:36:45 CEST] <andrey_turkin_> weird. I've checked on your Ellen sample (side by side original and with fps=30) and it was identical
[16:37:14 CEST] <prelude2004c> no idea .. i am compiling with x264 enabled to see if it makes a difference
[16:37:36 CEST] <andrey_turkin_> good idea
[16:37:41 CEST] <andrey_turkin_> though it shouldn't
[16:38:07 CEST] <prelude2004c> last time i got garbage from the stream.. x264 didn't .. was correct
[16:38:10 CEST] <prelude2004c> so checking that to be sure
[16:45:23 CEST] <andrey_turkin_> BtbN: looks like cuvid doesn't give sei specifically so you'd have to parse bitstream yourself to extract sei data
[16:45:35 CEST] <andrey_turkin_> and probably do the reordering
[16:45:48 CEST] <BtbN> So that's not going to happen.
[16:46:48 CEST] <andrey_turkin_> cuvid will packetize said bitstream for you but that's all
[16:57:44 CEST] <prelude2004c> odd.. libx264 i can't get video out .... strange strange.
[16:58:27 CEST] <prelude2004c> nevemrind, got it
[16:58:53 CEST] <prelude2004c> hey andrew_turkin_ , on x264 its correct
[16:58:54 CEST] <prelude2004c> the text is good
[16:59:31 CEST] <andrey_turkin_> this is reaaally strange
[16:59:48 CEST] <andrey_turkin_> I wonder if SEI processing somehow depends on a hardware too
[16:59:56 CEST] <andrey_turkin_> or on driver version. Or on nvenc SDK
[17:00:09 CEST] <prelude2004c> no idea ... but def. works on libx264
[17:00:24 CEST] <prelude2004c> hey question.. to introduce a further delay i can do that right ? from -1 to -2 for example
[17:00:55 CEST] <andrey_turkin_> not sure what do you mean
[17:01:22 CEST] <andrey_turkin_> it works fine on my system with nvenc. 
[17:01:59 CEST] <prelude2004c> very odd... maybe i am adding somethign to the line that is causing it.. let me get you my entire line
[17:02:39 CEST] <prelude2004c> http://pastebin.com/raw/4XyQRYDP
[17:03:09 CEST] <prelude2004c> also odd.. the complex filter fails a lot and then eventually starts up.. Error configuring complex filters.
[17:03:09 CEST] <prelude2004c> Invalid argument shows up a lot
[17:03:19 CEST] <prelude2004c> but it keeps trying and then sometimes catches
[17:04:30 CEST] <prelude2004c> seems to be input or something.. needs a longer analyze maybe
[17:04:42 CEST] <andrey_turkin_> combine_a53 is pretty hacky
[17:05:37 CEST] <prelude2004c> it works i guess.. asside from this nvenc thing it doesnt' stop like before like it did on x264
[17:05:58 CEST] <prelude2004c> before both had a problem.. did you setup a delay anywhere or can i setup a delay anywhere to bring cc closer to audio/video ?
[17:06:21 CEST] <andrey_turkin_> it should be in sync
[17:06:33 CEST] <prelude2004c> again minor issue at this point but.. just thinking it would be good to have :) .. its about 1 second off or something like that
[17:06:34 CEST] <andrey_turkin_> or at least as synced as it was in original
[17:06:39 CEST] <prelude2004c> maybe your right
[17:06:53 CEST] <prelude2004c> maybe its source.. that is the least of the problems :) .. so right now only the nvenc thing remains for hte most part
[17:08:25 CEST] <andrey_turkin_> what's your hardware?
[17:20:01 CEST] <andrey_turkin_> regarding video/subtitle sync (assuming you use live IP source) - just run two ffmpeg instance in parallel, one to do stream-copy of original video stream, second to do transcoding to file. And then check same place in both files
[17:20:45 CEST] <andrey_turkin_> you'll see whether any additional desync is introduced or not. Just let vlc play up to the comparison point so it gets enough of CC commands
[17:24:27 CEST] <prelude2004c> ok... i am not worried about the delay
[17:24:31 CEST] <prelude2004c> its like 1 sec.. not a big deal anyways
[17:24:40 CEST] <prelude2004c> i am using nvidia M4000 card
[17:24:55 CEST] <prelude2004c> so libx264 has no issues... i been watching and its 100% working
[17:25:17 CEST] <prelude2004c> so your code is working well.. now just to fix it on the nvenc .. it was a problem from the first time the code was written.. i had the same experience before too
[17:28:34 CEST] <prelude2004c> so odd.. took 4 times restarting ffmpeg for the encoding to start... kept complaining something about filter :) .
[17:28:38 CEST] <prelude2004c> but it starts after a little bit
[17:28:51 CEST] <andrey_turkin_> on linux or Windows?
[17:29:38 CEST] <prelude2004c> linux
[17:29:48 CEST] <prelude2004c> ubuntu 14
[17:29:55 CEST] <prelude2004c> ok so.. http://67.55.3.103/cbcvancouverhd1150vdpau/cbcvancouverhd1150vdpau.m3u8 that is now with nvenc
[17:30:04 CEST] <prelude2004c> if you use vlc and enable the teletext it shows it all messed up
[17:31:44 CEST] <andrey_turkin_> oh wow, it is really messed up
[17:33:11 CEST] <andrey_turkin_> yeah, that's not just command loss, this is total garbage
[17:34:02 CEST] <prelude2004c> yup.. i restarted the link sorry it would have stopped.. yes libx264 is clear no errors at all :) 
[17:34:27 CEST] <prelude2004c> font problem ? can't read that font ? i am just throwing things out there.. maybe not even relevent :) 
[17:34:28 CEST] <andrey_turkin_> it worked fine for me on Linux with kepler hardware. Going to try with Maxwells on windows to see if it changes anything
[17:34:43 CEST] <andrey_turkin_> doubtful
[17:35:44 CEST] <prelude2004c> ya the M4000 is great because they don't have that 2 stream limit... there is something else you should build :) ..on the consumer cards , you have a stream limit of 2 right.. so we have to build some sort of handler that will listen and send the commands to nvenc where it thinks its from 1 source but in fact you can input a bunch of channels into it.
[17:35:56 CEST] <prelude2004c> not sure what would be involved but basically creating a handler for it 
[17:36:00 CEST] <prelude2004c> i would pay for that :) 
[17:36:18 CEST] <andrey_turkin_> you really can't do that
[17:36:20 CEST] <prelude2004c> M4000 cards are soo expensive and the consumer cards are just as fast
[17:36:36 CEST] <andrey_turkin_> oh i know. but we had to buy M4000 too 
[17:36:54 CEST] <prelude2004c> oh it was an idea.... i figure when it comes to programming.. " can't do that is just code for ( not easy to do ) " because anything is possible :) 
[17:37:18 CEST] <andrey_turkin_> you really can't shove many streams into single encoder
[17:37:49 CEST] <prelude2004c> the other thing... you know how it uses the onboard encoder/decoder.. what about the cuda cores that are just sitting there.. we should find a way to use all the cores. and really max out the cards capabilities
[17:38:06 CEST] <prelude2004c> i know its not as good as hardware encoding but.. at least it will be 1 or 2 more channels 
[17:38:27 CEST] <prelude2004c> will trully push video cards to their limit.. i doubt quality is as good too but at least you can throw up the SD content on it
[17:39:34 CEST] <andrey_turkin_> maybe better buy some good Intel CPU? and push some channels onto that onboard GPU
[17:39:38 CEST] <andrey_turkin_> and then some to CPU itself )
[17:40:06 CEST] <prelude2004c> yup.. i use good cpu's on some systems but the problem is you start to loose some UDP data when you push them too far
[17:40:25 CEST] <prelude2004c> but def. worth a try i guess :P
[17:40:57 CEST] <andrey_turkin_> that should be solvable by pinning threads to a certain cores
[17:41:00 CEST] <prelude2004c> i should use the CPU's for sure.. might as well try it.. maybe i will get good performace now that i got the VDpau & the nvenc working well for hte most part
[17:41:25 CEST] <andrey_turkin_> libx264 works wonders on modern CPUs
[17:41:50 CEST] <prelude2004c> possibly.. using threads 3 for example limits to 3 threads. is there some param to push the threads to say CPU 0, 1 , 2 and then another one to 3 , 4 ,5 , etc
[17:42:12 CEST] <prelude2004c> yup i was using h264 today so i can't be sure it was even using libx264
[17:42:14 CEST] <andrey_turkin_> e.g. I've got E5-1650 v3 here and difference between libx264 and nvenc is not that large
[17:42:16 CEST] <prelude2004c> i learned that last week :) 
[17:42:40 CEST] <prelude2004c> yes i will give that a shot too
[17:43:36 CEST] <andrey_turkin_> you can set CPU affinity to a process, and do the same to kernel threads. HPC people and people who deal with large network traffic do that all the time
[17:43:51 CEST] <prelude2004c> yup i can do that
[17:43:54 CEST] <prelude2004c> ok np.. makes sense
[18:34:57 CEST] <prelude2004c> andrey_turkin_ .. i also saw a VBV Underflow error
[18:34:59 CEST] <prelude2004c> so you know
[18:35:02 CEST] <prelude2004c> not sure if it means anything but...
[18:51:26 CEST] <jkqxz> That probably just means that the screen was blank for a while so the encoder wasn't able to waste enough bits to get to the bitrate target.  If you really want CBR then you can add filler NAL units to waste the bits directly.
[18:55:44 CEST] <prelude2004c> i don't think that was for me :) .. i am using vbr 
[18:56:02 CEST] <prelude2004c> i think that's related to the new andrey_turkin_ code ( possibly )
[18:56:45 CEST] <JEEB> jkqxz: underflow actually means that you're running out of buffer bits ;)
[18:57:12 CEST] <JEEB> you don't get an error when you're not using bits, you get that when the encoder couldn't keep your shit within the parameters you set
[18:57:13 CEST] <rcombs> out of curiosity, under what circumstances is "too few bits used to code video" a problem?
[18:57:31 CEST] <JEEB> it isn't, except when you're doing a CBR mux. which is a very, very limited use case
[18:57:41 CEST] <rcombs> what's that useful for, though
[18:58:15 CEST] <JEEB> broadcast people can answer to you regarding True CBR and how its positives have nothing to do with image quality or compression
[18:58:56 CEST] <andrey_turkin> it's really not
[18:59:01 CEST] <andrey_turkin> related to my code
[18:59:16 CEST] <rcombs> yeah, I'm just curious
[18:59:19 CEST] <JEEB> yes, this was a general question and jkqxz misunderstood the error message
[19:09:16 CEST] <BtbN> Damn, linking libnpp? statically is a mess.
[19:15:36 CEST] <BtbN> And for some reason they only have those static libs on linux
[19:17:44 CEST] <andrey_turkin> and only 64-bit on Windows
[19:20:34 CEST] <BtbN> Well, I don't care too much about that.
[19:35:54 CEST] <jkqxz> Sending over fixed-width channels is the usual place you want filler, though generally you prefer the transport to do it rather than the VCL.  (H.320 over ISDN wanted it, say.)
[19:37:55 CEST] <andrey_turkin> not many uses nowadays; main fixed-width channel users are probably broadcast providers
[19:38:28 CEST] <andrey_turkin> and they really wouldn't want to waste any bandwidth
[19:43:46 CEST] <jkqxz> Hmm, yes.  The underflow there is that the CPB on decode does not contain the bits you need when you want to decode them, not that the CPB on send does not contain the bits when they want to be sent.  Apologies for any confusion.
[19:44:48 CEST] <jkqxz> (Because it is all phrased in terms of the CPB for the HRD, even when it's actually an encoder you are talking about.)
[20:01:54 CEST] <BtbN> Does interlaced encoding work at all? Or is avctx->flags &= AV_CODEC_FLAG_INTERLACED_DCT; not enough to trigger it?
[20:10:30 CEST] <andrey_turkin> I think you also need to set interlacing info for the frames?
[20:10:40 CEST] <andrey_turkin> also did you mean |= ?
[20:13:21 CEST] <BtbN> yes... yes I did.
[20:14:16 CEST] <BtbN> at least nvenc only evalutates that flag(which was never set for that reason, so have to re-test...), and frame->top_field_first, which is set.
[20:16:32 CEST] <BtbN> nope, still progressive output
[20:16:38 CEST] <BtbN> I wonder if something in nvenc is missing for this.
[20:47:28 CEST] <BtbN> No idea what is happening with deinterlacing. I'm quite sure the cuvid decoder is doing everything correctly.
[21:04:14 CEST] <BtbN> Looks like my card/driver just plain doesn't support it. Will add a check for it.
[21:47:07 CEST] <BtbN> can anyone think of what the difference between 1 and 2 is? https://github.com/jp9000/OBS/blob/master/ObsNvenc/inc/nvEncodeAPI.h#L644
[21:47:38 CEST] <BtbN> I have 1. And as it's not working, I assume 2 is needed.
[21:47:49 CEST] <BtbN> But I'm not sure what the difference is.
[21:58:17 CEST] <DHE> de-interlace by turning 1 frame into 2, or by just deinterlacing the frame
[21:58:31 CEST] <DHE> or, other way around I guess for an encoder
[21:59:20 CEST] <cone-588> ffmpeg 03Michael Niedermayer 07master:a5eb70ad9569: avformat/mpegts: Do not trust BSSD descriptor, it is sometimes not an S302M stream
[22:05:06 CEST] <BtbN> ah, so mode 2 actually takes 2 full frames, and outputs one interlace?
[22:05:43 CEST] <BtbN> Well, in that case cap 1 should be enough, as the frame already has two fields
[22:05:49 CEST] <BtbN> but it doesn't work
[22:20:07 CEST] <BtbN> nevcairiel, if I don't set frame->pkt_pts, i get dropped frames and tons of past duration too large. But shouldn't ff_decode_frame_props take care of that field?
[22:20:47 CEST] <nevcairiel> it does
[22:21:12 CEST] <BtbN> ohh, it uses the avctx internal pkt for that...
[22:21:17 CEST] <BtbN> which is for a way more recent frame
[22:21:20 CEST] <BtbN> because of the queue
[22:23:22 CEST] <BtbN> hm, so I also have to queue those parameters? oO
[22:27:00 CEST] <nevcairiel> you could queue a full avframe and fill the info when you put it inot the queue
[22:27:09 CEST] <nevcairiel> otherwise it probably screws over many things
[22:27:26 CEST] <nevcairiel> pts should also be re-ordered,  so thats probably going to be problematic
[22:27:40 CEST] <nevcairiel> hm, wait, decoder should set pkt_pts themself, not pts
[22:27:44 CEST] <nevcairiel> i confused it with pkt_dts
[22:28:20 CEST] <BtbN> the pts is propperly re-ordered, because it's passed through cuvid
[22:28:34 CEST] <nevcairiel> yeah set pkt_pts to that
[22:28:42 CEST] <nevcairiel> let the fill function fill in everything else
[22:29:45 CEST] <BtbN> so frame->pts is left unset?
[22:30:09 CEST] <nevcairiel> probably no harm to set it to the pts as well
[22:30:14 CEST] <nevcairiel> i forget the exact rules
[22:30:24 CEST] <nevcairiel> might be able to check another "simple" decoder
[22:32:00 CEST] <BtbN> looks like only qsv and vp9 set it at all
[22:32:18 CEST] <nevcairiel> its generally the input for encoders
[22:32:24 CEST] <nevcairiel> but not output of decoders
[22:32:27 CEST] <nevcairiel> terrible api ahoy =p
[22:32:57 CEST] <nevcairiel> not sure if some generic code copies it around
[22:33:08 CEST] <BtbN> Shouldn't this be a problem for all decoders that have a delay?
[22:33:39 CEST] <BtbN> Or do they just alloc the output frame right away, and then queue it?
[22:33:51 CEST] <nevcairiel> i believe thats what many do
[22:34:02 CEST] <BtbN> Kind of complicated in the CUDA output case
[22:34:03 CEST] <nevcairiel> output the frame at decoding time, and then re-order that
[22:34:13 CEST] <nevcairiel> yeah because the re-ordering is opaque
[22:35:16 CEST] <BtbN> I'll just override the pkt_ fields, should work fine.
[22:37:08 CEST] <BtbN> Why is there even a distinction between pts and pkt_pts?
[22:37:19 CEST] <nevcairiel> who knows
[22:39:35 CEST] <andrey_turkin> there are various algorithms to fix pts before encoding it
[22:39:38 CEST] <andrey_turkin> maybe pkt_pts is the way to get "raw" pts?
[22:39:40 CEST] <BtbN> Can't I just alloc a frame on decode, call ff_decode_frame_props on it, then queue that, and finally call av_frame_copy_props from that queued frame to the output frame?
[22:41:25 CEST] <BtbN> Yeah, seems like that would work
[22:42:25 CEST] <nevcairiel> that sounds fine
[22:43:17 CEST] <BtbN> Don't even need to queue it, I can just abuse the cuvid picture index.
[22:46:23 CEST] <BBB> michaelni: so what do you want to do with the avclass/* vote?
[22:55:16 CEST] <jamrial> was it a tie?
[22:56:01 CEST] <BtbN> 4:4 iirc
[23:02:06 CEST] <michaelni> BBB ill just wait until someone adds one more vote or withdraw mine, i wanted to fix more bugs before the release anyway
[23:02:32 CEST] <BBB> michaelni: well you said 7 days, and the vote started 8-9 days ago
[23:02:41 CEST] <BBB> michaelni: so if you want to extend, you should at least announce that
[23:02:48 CEST] <michaelni> ok
[23:02:55 CEST] <BBB> (like, make it another week)
[23:06:11 CEST] <jkqxz> How about adding a void* placeholder to the structure now, but don't implement anything?  Then later if someone comes up with a compelling reason for it that everyone can agree on there are not horrible ABI issues, but it doesn't actually get implemented until that happens.
[23:06:48 CEST] <BtbN> because it's not pointer sized i guess.
[23:10:29 CEST] <BBB> michaelni: its unclear at this point if its 7 days from now or 7 days extra on top of the original 7 days, i.e. is the final date Sun, May 29, 2016 at 01:32:54AM + 14 days or is it Mon Jun 6 5:10 GMT-5 +7 days?
[23:10:37 CEST] <atomnuker> it's controversial, even Daemon404 was against it
[23:10:51 CEST] <atomnuker> I'm not sure merging controversial stuff right now is a good idea
[23:13:29 CEST] <BtbN> nevcairiel, nope, also doesn't work. Runs into the same issue. You have no idea what kind of re-ordering cuvid did, and no way to track it.
[23:14:16 CEST] <BtbN> the only thing it re-orders for you is exactly one timestamp, that's it.
[23:15:15 CEST] <jamrial> atomnuker: that's why there's a vote
[23:15:30 CEST] <BtbN> So manually setting/clearing those pkt_ fields it is.
[23:23:07 CEST] <BtbN> Uhm, where is av_frame_get/set_best_effort_timestamp implemented? I only see the declaration in frame.h and a couple places that use it?
[23:23:21 CEST] <nevcairiel> probably from a macro
[23:23:27 CEST] <nevcairiel> it just sets the frame of the same name
[23:24:16 CEST] <BtbN> ah, MAKE_ACCESSORS
[23:53:22 CEST] <cone-588> ffmpeg 03Timo Rothenpieler 07master:808356c61c6e: avcodec/nvenc: Check capabilities for interlaced encoding
[23:56:58 CEST] <pfelt1> ty michaelni :)
[23:57:31 CEST] <michaelni> np, it was a good idea
[23:58:13 CEST] Action: pfelt1 notes that.  he only gets a few of them.  *cough*
[23:58:20 CEST] <pfelt1> i guess my quota is up
[00:00:00 CEST] --- Tue Jun  7 2016