________________________________

	From: ext Milko Boic [mailto:milko at real.com] 
	Sent: Tuesday, October 25, 2005 5:55 PM
	To: Gupta Ashish.As (Nokia-TP-MSW/Irving);
datatype-dev at lists.helixcommunity.org
	Subject: Re: [datatype-dev] QTFileFormat and Framesize
	
	
	At 11:48 AM 10/25/2005, Ashish.As.Gupta at nokia.com wrote:
	

		Hi,
		QTFileFormat is storing TrackWidth/TrackHeight in the
Headers as
		"Width"/"Height". For network playback, width and height
information is
		available through SDP and it is stored in "FrameWidth"
and
		"FrameHeight".
		
		vidrend.cpp calls CheckVideoAreaSize during the
UpdateDisplay() and
		rejects the clip if it is larger than a pref value. I
believe this
		happens when Initialization is over and it is actually
decoding.
		
		I would like to make following additions to the
functionality:
		
		1. Each video format stores the frame width/height
information in the
		Stream Header so that it is available to TLC and
Renderers. I am hoping
		to extract this information by parsing
SampleDescriptions. This
		information will be stored as "FrmaeWidth" and
"FrameHeight".
		I see for H.263 FrameWidth/FrameHeight is parsed but not
sure if other
		(MP4V/AVC) sample descriptions are parsed to extract the
same
		information.
		This will add GetFrameWidth/GetFrameHeight to CQTTrack
to be used by
		CQTFileFormat.


	- mp4 file format is a container file format and it will be
difficult to maintain parsing of FrameWidth and FrameHeight for every
datatype that can reside within it
	- in some cases obtaining FrameWidth and FrameHeight is
difficult and requires much code that belong to decoding and
depacketization side and not file reading.  Placing this code into the
file format will result in increased image size and possibly duplicate
functionality which already exists in decoder or renderer
	- this clearly does not work for streamed content
	
	Thus, setting of FrameWidth and FrameHeight into the stream
header should be done by datatype specific derivation of HX_RESULT
CVideoFormat::Init(IHXValues* pHeader) .
	Then, the generic check in vidrend.cpp in OnHeader can ba made
after m_pVideoFormat->Init(pHeader); is invoked.
	
	The existing code that sets FrameWidth and FrameHeight in
vidrend.cpp should be used as the fallback only if FrameWidth and
FrameHeight are not already set in the stream header.
	
	
	

		2. All the Renderers should check previously stored
		FrameWidth/FrameHeight against
"MaxVideoWidth"/"MaxVideoHeight" during
		OnHeader().
		Checking here allows the partial playback for clips when
Video Size is
		larger than the maximum supported size.


	That will happen automatically by the virtue of the check being
implemented in the base video renderer.
	However, each video renderer will have to implement a way to
supply FrameWidth and FrameHeight into the stream header when available.
	Note that ESD and other data-type specific descriptors are
passed to the renderer as "OpaqueData" Buffer in the stream header for
local playback streams.
	For streamed content, the availability of FrameWidth and
FrameHeight in OnHeader depends on payload specification for a datatype.
	 
	I was looking into datatype/mp4/common/mp4desc.cpp but couldn't
see where this information is available. For H.263, "OpaqueData"
contains DecoderSpecific info that doesn't contain the FrameWidth and
FrameHeight, so for this datatype can we use the already parsed
information in fileformat?  For streaming H.263, it is already available
from SDP.
	 
	Milko
	
	
	

		Please let me know if anyone has any suggestions on
this.
		
		Thanks
		Ashish
		
		_______________________________________________
		Datatype-dev mailing list
		Datatype-dev at helixcommunity.org
	
http://lists.helixcommunity.org/mailman/listinfo/datatype-dev