[prev in list] [next in list] [prev in thread] [next in thread] 

List:       helix-datatype-cvs
Subject:    [Datatype-cvs] tools/dtdriver/decoder/video/pub vdecoder.h, 1.4,
From:       ehyche () helixcommunity ! org
Date:       2008-02-20 23:42:15
Message-ID: 200802202342.m1KNgiQU011588 () mailer ! progressive-comp ! com
[Download RAW message or body]

Update of /cvsroot/datatype/tools/dtdriver/decoder/video/pub
In directory cvs01.internal.helixcommunity.org:/tmp/cvs-serv5443/pub

Modified Files:
      Tag: hxclient_3_1_0_atlas
	vdecoder.h 
Log Message:
Merge from HEAD to 310Atlas.

Description
---------------------------------------------
dtdrplin is used by several applications for thumbnail
generation. Applications usually pick a fixed time (like
5s into the clip) and call dtdrplin with the following
options to generate a thumbnail:

"StartTime"        = 5000
"ProcessTimeUnits" = 1

StartTime=5000 tells dtdrplin to seek the file format to 5000ms
before start fetching packets and passing them through
the pipeline. ProcessTimeUnits=1 tells dtdrplin to only
fetch enough packets that represent 1 unique timestamp.
Usually this 1 unique timestamp will wind up being the
packet (or packets) for the first keyframe prior to
the specified StartTime.

The problem is with vidrend-based renderers (video renderers
which derive from the base video renderer) on the HEAD
and atlas branches. When these renderers are seeked,
they expect to receive packets from the prior keyframe
forward. They decode these packets, but they do not 
begin bltting frames until they see a frame that is
greater than or equal to the desired seek time.

But since for ProcessTimeUnits=1, we are only fetching
enough packets for usually one frame (the keyframe
prior to the seek time), then these renderers usually
wind up not bltting anything, which means no thumbnail
is generated.

So the fix for this is when we detect that ProcessTimeUnits
is set, we call OnPreSeek/OnPostSeek/OnBegin with the
time of the first packet that the fileformat gives us
prior to the seek time rather than the seek time itself.
This ensures that the video renderers will blt the initial
frame, without requiring any changes to sensitive code
in the base video renderer.

Files Modified
---------------------------------------------
datatype/tools/dtdriver/decoder/video/vdecoder.cpp
datatype/tools/dtdriver/decoder/video/pub/vdecoder.h

Branches
---------------------------------------------
HEAD and 310Atlas



Index: vdecoder.h
===================================================================
RCS file: /cvsroot/datatype/tools/dtdriver/decoder/video/pub/vdecoder.h,v
retrieving revision 1.4
retrieving revision 1.4.18.1
diff -u -d -r1.4 -r1.4.18.1
--- vdecoder.h	14 Mar 2005 19:24:56 -0000	1.4
+++ vdecoder.h	20 Feb 2008 23:42:13 -0000	1.4.18.1
@@ -107,6 +107,7 @@
     ULONG32		    m_ulPreviousPacketTime;
     ULONG32		    m_ulPacketCount;
     ULONG32		    m_ulBltCount;
+    ULONG32                 m_ulProcessTimeUnits;
 
     HX_BITFIELD             m_bMaxSpeed : 1;
     HX_BITFIELD             m_bProcessHeadersOnly : 1;


_______________________________________________
Datatype-cvs mailing list
Datatype-cvs@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/datatype-cvs
[prev in list] [next in list] [prev in thread] [next in thread]