Req "Demuxer" for separate streams - Printable Version +- Kodi Community Forum (https://forum.kodi.tv) +-- Forum: Development (https://forum.kodi.tv/forumdisplay.php?fid=32) +--- Forum: Kodi Application (https://forum.kodi.tv/forumdisplay.php?fid=93) +---- Forum: VideoPlayer Development (https://forum.kodi.tv/forumdisplay.php?fid=240) +---- Thread: Req "Demuxer" for separate streams (/showthread.php?tid=255626) |
RE: "Demuxer" for separate streams - FernetMenta - 2016-01-12 (2016-01-12, 11:59)peak3d Wrote:(2016-01-12, 11:39)FernetMenta Wrote:(2016-01-12, 10:34)peak3d Wrote: From timing its not the big difference if I use SW rendering, Pixel-shaders != sw rendering. sw rendering is an ancient method that does yuv to rgb conversion in CPU. If you disable dxva and leave render method to auto, pixel shaders will be selected. RE: "Demuxer" for separate streams - peak3d - 2016-01-12 (2016-01-12, 11:42)FernetMenta Wrote:(2016-01-12, 10:34)peak3d Wrote: a) Build up early new RenderManager at the time we detect the change But you have to keep track about the order of the displayed frames - At least the flushing of the buffered frames (from data before change) must be processed in renderer before the new ones will be touched. Because of this I could think that letting the render find the best time to switch would be the best - and it doesn't block anymore if the new frames are simply pushed to it. I could imagine this workflow: - change is detected (some seconds before display) and the renderer preconfigures as much as it can (most things for initializing are available in hints) - decoded frames are pushed to Renderer - decoder detects the change and switches to the preconfigured processor or renderer or whatever is the best. RE: "Demuxer" for separate streams - FernetMenta - 2016-01-12 you forgot that there can only be singe renderer at a given time. configuring renderer is instant. why don't you try as I suggested. continue decoding while renderer plays out remaining frames. as soon as last frame comes to display you can feed renderer again. RE: "Demuxer" for separate streams - peak3d - 2016-01-12 because I don't know where to put the decoded frames to. Decode accesses direct renderer buffer, doesn't it? RE: "Demuxer" for separate streams - FernetMenta - 2016-01-12 you could do in dxva decoder like vaapi and vdpau do: https://github.com/xbmc/xbmc/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/Video/VAAPI.cpp#L767 they don't deliver pics (VC_PICTURE) as long as the buffers are not full: https://github.com/xbmc/xbmc/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/Video/VAAPI.cpp#L825 This way decoder can do work while the videoplayer thread is blocked by renderer. RE: "Demuxer" for separate streams - peak3d - 2016-01-12 thx, I'll look at it RE: "Demuxer" for separate streams - peak3d - 2016-01-12 I have changed so far: 1.) Allocate one priority buffer in RenderManager to make sure that the last "old" frame (the one before Change message) has not to wait for RenderBuffers. -> This leads to the fact, that initialization starts faster. 2.)- RenderManager::AddVideoPicture() will be called directly inside the lock scope of RenderManger::configure if a change occured -> This removes the black frame thing 3.) Still 0.1 seconds gap. I looked deeper to the DTS / PTS of the video packets after the change: P1.) 18:14:27:0871 T:19556 DEBUG: CVideoPlayerVideo:ecoding 20020000.000000 - 20103416.666667 - 2 P2.) 18:14:27:0873 T:19556 DEBUG: CVideoPlayerVideo:ecoding 20061708.333333 - 20270250.000000 - 6 First packet cannot produce a picture (2 = VC_BUFFER), but the second one (VC_BUFFER | VC_PICTURE). But: the PTS of the of the second packet is far away from be displayed directly, its about 0.17 sec. behind the packet 1. In later packets there will be PTS wich are closer to the first one (this is Packet 3). P3 18:14:27:0944 T:19556 DEBUG: CVideoPlayerVideo:ecoding 20103416.666667 - 20186833.333333 - 6 Im not professional in Mpeg, but what is with the first packet? Shouldn't this be displayed at 20103416.666667 after it was updated with packet 2? Or is Packet 1 simply garbage? RE: "Demuxer" for separate streams - FernetMenta - 2016-01-12 (2016-01-12, 19:32)peak3d Wrote: Im not professional in Mpeg, but what is with the first packet? Shouldn't this be displayed at 20103416.666667 after it was updated with packet 2? I don't know where you put your logs. I guess before decoding. Due to b-frames packets going into decoder can have different ordering. Before decoding look at dts, after decoding at pts. RE: "Demuxer" for separate streams - peak3d - 2016-01-12 currently I have 2 LogPositions in VideoPlayerVideo.cpp: Process() behind: int iDecoderState = m_pVideoCodec->Decode(pPacket->pData, pPacket->iSize, pPacket->dts, pPacket->pts); OutputPicture() before: m_renderManager.FlipPage(CThread::m_bStop, (iCurrentClock + iSleepTime) / DVD_TIME_BASE, pts_org, -1, mDisplayField); And yes, it is now visible that the main problem is not directly on Change, but at around the time of the packet 2: Code: 18:51:48:0746 T:9820 DEBUG: CRenderManager::Configure - 3 This is the .1 second Im searching for. The packet is decoded but has to wait for renderbuffers 0.17 secs RE: "Demuxer" for separate streams - FernetMenta - 2016-01-12 (2016-01-12, 20:08)peak3d Wrote: This is the .1 second Im searching for. The packet is decoded but has to wait for renderbuffers 0.17 secs Did you buffer the frames in decoder as I suggested? RE: "Demuxer" for separate streams - peak3d - 2016-01-12 (2016-01-12, 20:54)FernetMenta Wrote:(2016-01-12, 20:08)peak3d Wrote: This is the .1 second Im searching for. The packet is decoded but has to wait for renderbuffers 0.17 secs I'll do this next - I spend the day searching for the black frame. What I still don't understand: What is with the first packet (of the second part): 18:14:27:0871 T:19556 DEBUG: CVideoPlayerVideo:ecoding 20020000.000000 - 20103416.666667 - 2 (=VC_BUFFER) ?? This is the one wich should go directly after the last of the first part of the video. Is it really lost? What is with the 1753 Byte of data in this first packet? RE: "Demuxer" for separate streams - peak3d - 2016-01-12 I need onother thing clear before I start buffering: For me it seems that the number of RenderBuffers are not sufficient for thie initial sequence. The freeze occurs after all te change stuff is done, Simpy buffering would not solve the problem with 2 Renderbuffers available I also have to sort them, is this right? [Edit:] Forget this, there is a buffer for it - but I found a sleeptime just before the freeze with 0.169 secs RE: "Demuxer" for separate streams - FernetMenta - 2016-01-12 (2016-01-12, 21:01)peak3d Wrote: Is it really lost? What is with the 1753 Byte of data in this first packet? why lost? you won't get a pic for every packet you put into decoder. packets are reordered and frames have references to others. btw: dxva does not have drain implemented. that means that you don't get the last frames out of decoder as we get from sw decoder, vaapi, vdpau or mmal. that is why dxva gets deactivated for DVDs that can contain still frames. You need to squeeze out remaining frames after the last frame went into decoder. RE: "Demuxer" for separate streams - peak3d - 2016-01-12 1.) This means: on initialization there are for- and backward jumps - but if the decoder is filled then it produces ordered frames (all regarding PTS)? 2.) Is it right that I cannot call Decoder::GetPicture() during Render-reconfiguring because the memory applied to an DVDImage is physically the memory allocated from the Renderbuffer? -> Its decoder memory, you don't have to answer this 3.) How many Image Buffers can I allocate in Renderer with common Hardware? RE: "Demuxer" for separate streams - FernetMenta - 2016-01-13 (2016-01-12, 23:41)peak3d Wrote: 1.) This means: on initialization there are for- and backward jumps - but if the decoder is filled then it produces ordered frames (all regarding PTS)? Wrong. PTS never jumps after decoder (GetPicture) (2016-01-12, 23:41)peak3d Wrote: 2.) Is it right that I cannot call Decoder::GetPicture() during Render-reconfiguring because the memory applied to an DVDImage is physically the memory allocated from the Renderbuffer? Wrong. Either a pic is copied into render buffers or a ref counted surface flows from decoder to renderer. re-configure of renderer would then release the surfaces. (2016-01-12, 23:41)peak3d Wrote: 3.) How many Image Buffers can I allocate in Renderer with common Hardware?[/quote] depends on GPU mem but I doubt you would ever need more than 5 |