From ehyche at real.com Mon Apr 2 10:24:53 2007
From: ehyche at real.com (Eric Hyche)
Date: Mon Apr 2 10:55:09 2007
Subject: [Filesystem-dev] File Seek in the beginning of streaming
In-Reply-To:
References:
<00fa01c76be1$75bca760$db68a8c0@EHYCHED620>
Message-ID: <03c701c7754b$d4c86b90$db68a8c0@EHYCHED620>
Not sure off the top of my head. I would step through
the file format plugin in a debugger to be sure.
The .3gp file format is located in datatype/mp4/fileformat.
Eric
=============================================
Eric Hyche (ehyche@real.com)
Technical Lead
RealNetworks, Inc.
> -----Original Message-----
> From: ken carlino [mailto:ken.carlino@gmail.com]
> Sent: Friday, March 23, 2007 10:05 PM
> To: ehyche@real.com
> Cc: filesystem-dev@helixcommunity.org
> Subject: Re: [Filesystem-dev] File Seek in the beginning of streaming
>
> On 3/21/07, Eric Hyche wrote:
> >
> > What kind of file is being streamed?
> >
> > Most likely this is a type of file that doesn't
> > have the necessary header information at the beginning
> > of the file (i.e. - mp3). Therefore, the file format
> > plugin has to seek to the end of the file to get
> > some information before going back and starting
> > to deliver packets.
> >
>
> Thanks. I am trying to stream 3gp.
>
> After reading your response, I use a tool from FFmpeg which
> moves moov atom
> to the front. But after I use this to convert the movie and use Helix
> to stream,
> i still see Helix to seek to the end of the move before seek back to
> the top of the movie and start streaming.
>
> Can you please help me understand why helix still needs to seek to the
> end of the move?
>
> Thank you.
>
>
> // Details of the qt-faststart:
>
> * This utility rearranges a Quicktime file such that the moov atom
> * is in front of the data, thus facilitating network streaming.
> *
> * Compile this program using:
> * make qt-faststart
> * Invoke the program with:
> * qt-faststart
> *
> * Notes: Quicktime files can come in many configurations of top-level
> * atoms. This utility stipulates that the very last atom in
> the file needs
> * to be a moov atom. When given such a file, this utility
> will rearrange
> * the top-level atoms by shifting the moov atom from the
> back of the file
> * to the front, and patch the chunk offsets along the way.
> This utility
> * presently only operates on uncompressed moov atoms.
>
>
>
> > Eric
> >
> > =============================================
> > Eric Hyche (ehyche@real.com)
> > Technical Lead
> > RealNetworks, Inc.
> >
> > > -----Original Message-----
> > > From: filesystem-dev-bounces@helixcommunity.org
> > > [mailto:filesystem-dev-bounces@helixcommunity.org] On Behalf
> > > Of ken carlino
> > > Sent: Wednesday, March 21, 2007 12:32 PM
> > > To: filesystem-dev@helixcommunity.org
> > > Subject: [Filesystem-dev] File Seek in the beginning of streaming
> > >
> > > Hi,
> > > I am trying to study the behavior of FileStream in the
> beginning of
> > > streaming in Helix.
> > > I notice that Helix first tries to seek to end of the
> file, read 4K
> > > off the file and then re-seek the file to the beginning and start
> > > streaming from there.
> > >
> > > My question is why it seeks to the end of the file in the
> beginning?
> > >
> > > Thank you.
> > >
> > > _______________________________________________
> > > Filesystem-dev mailing list
> > > Filesystem-dev@helixcommunity.org
> > > http://lists.helixcommunity.org/mailman/listinfo/filesystem-dev
> > >
> >
> >
>
From ken.carlino at gmail.com Mon Apr 2 21:22:21 2007
From: ken.carlino at gmail.com (ken carlino)
Date: Mon Apr 2 21:52:37 2007
Subject: [Filesystem-dev] File Seek in the beginning of streaming
In-Reply-To: <03c701c7754b$d4c86b90$db68a8c0@EHYCHED620>
References:
<00fa01c76be1$75bca760$db68a8c0@EHYCHED620>
<03c701c7754b$d4c86b90$db68a8c0@EHYCHED620>
Message-ID:
Thanks. Can you please tell me how can i just debug the file format plugin
after I start Helix server?
On 4/2/07, Eric Hyche wrote:
>
> Not sure off the top of my head. I would step through
> the file format plugin in a debugger to be sure.
> The .3gp file format is located in datatype/mp4/fileformat.
>
> Eric
>
> =============================================
> Eric Hyche (ehyche@real.com)
> Technical Lead
> RealNetworks, Inc.
>
> > -----Original Message-----
> > From: ken carlino [mailto:ken.carlino@gmail.com]
> > Sent: Friday, March 23, 2007 10:05 PM
> > To: ehyche@real.com
> > Cc: filesystem-dev@helixcommunity.org
> > Subject: Re: [Filesystem-dev] File Seek in the beginning of streaming
> >
> > On 3/21/07, Eric Hyche wrote:
> > >
> > > What kind of file is being streamed?
> > >
> > > Most likely this is a type of file that doesn't
> > > have the necessary header information at the beginning
> > > of the file (i.e. - mp3). Therefore, the file format
> > > plugin has to seek to the end of the file to get
> > > some information before going back and starting
> > > to deliver packets.
> > >
> >
> > Thanks. I am trying to stream 3gp.
> >
> > After reading your response, I use a tool from FFmpeg which
> > moves moov atom
> > to the front. But after I use this to convert the movie and use Helix
> > to stream,
> > i still see Helix to seek to the end of the move before seek back to
> > the top of the movie and start streaming.
> >
> > Can you please help me understand why helix still needs to seek to the
> > end of the move?
> >
> > Thank you.
> >
> >
> > // Details of the qt-faststart:
> >
> > * This utility rearranges a Quicktime file such that the moov atom
> > * is in front of the data, thus facilitating network streaming.
> > *
> > * Compile this program using:
> > * make qt-faststart
> > * Invoke the program with:
> > * qt-faststart
> > *
> > * Notes: Quicktime files can come in many configurations of top-level
> > * atoms. This utility stipulates that the very last atom in
> > the file needs
> > * to be a moov atom. When given such a file, this utility
> > will rearrange
> > * the top-level atoms by shifting the moov atom from the
> > back of the file
> > * to the front, and patch the chunk offsets along the way.
> > This utility
> > * presently only operates on uncompressed moov atoms.
> >
> >
> >
> > > Eric
> > >
> > > =============================================
> > > Eric Hyche (ehyche@real.com)
> > > Technical Lead
> > > RealNetworks, Inc.
> > >
> > > > -----Original Message-----
> > > > From: filesystem-dev-bounces@helixcommunity.org
> > > > [mailto:filesystem-dev-bounces@helixcommunity.org] On Behalf
> > > > Of ken carlino
> > > > Sent: Wednesday, March 21, 2007 12:32 PM
> > > > To: filesystem-dev@helixcommunity.org
> > > > Subject: [Filesystem-dev] File Seek in the beginning of streaming
> > > >
> > > > Hi,
> > > > I am trying to study the behavior of FileStream in the
> > beginning of
> > > > streaming in Helix.
> > > > I notice that Helix first tries to seek to end of the
> > file, read 4K
> > > > off the file and then re-seek the file to the beginning and start
> > > > streaming from there.
> > > >
> > > > My question is why it seeks to the end of the file in the
> > beginning?
> > > >
> > > > Thank you.
> > > >
> > > > _______________________________________________
> > > > Filesystem-dev mailing list
> > > > Filesystem-dev@helixcommunity.org
> > > > http://lists.helixcommunity.org/mailman/listinfo/filesystem-dev
> > > >
> > >
> > >
> >
>
>
From gwright at real.com Tue Apr 3 13:01:57 2007
From: gwright at real.com (Greg Wright)
Date: Tue Apr 3 13:32:02 2007
Subject: [Filesystem-dev] CR: RESEND, Allow overrides of growth limits....
In-Reply-To: <460DB01F.7060409@real.com>
References: <460DB01F.7060409@real.com>
Message-ID: <4612B2B5.7030009@real.com>
I am going to go ahead and check this into HEAD today
if I don't hear anything further....
--greg.
Greg Wright wrote:
> We need to be able to change the floor and ceiling values depending
> on the build target:
>
> #define CHUNK_RES_MEM_FLOOR 512000 //512 KB
> #define CHUNK_RES_MEM_CEILING 1000000 // 1MB
>
> This change just uses the defaults only if they are not defined
> already. Then I just define them in the OLPC profile as needed.
>
> After this change, HTTP streaming works on the XO (olpc) for SMIL,
> RV, Ogg and other datatypes.
>
> HEAD only.
>
> --greg.
>
>
>
> Index: httpfsys.h
> ===================================================================
> RCS file: /cvsroot/filesystem/http/httpfsys.h,v
> retrieving revision 1.38
> diff -u -w -r1.38 httpfsys.h
> --- httpfsys.h 8 Mar 2006 02:28:35 -0000 1.38
> +++ httpfsys.h 31 Mar 2007 00:46:22 -0000
> @@ -103,11 +103,16 @@
> #define DEFAULT_CHUNK_SIZE 1024 //default size of chunk buffer
>
> #ifdef HELIX_FEATURE_HTTPFSYS_MEM_GROWTH_LIMIT
> +# if !defined(CHUNK_RES_MEM_FLOOR)
> +# define CHUNK_RES_MEM_FLOOR 512000
> +# endif
> +# if !defined(CHUNK_RES_MEM_CEILING)
> +# define CHUNK_RES_MEM_CEILING 1000000
> +# endif
> +#endif //HELIX_HTTPFSYS_MEM_GROWTH_LIMIT
> +
>
> -#define CHUNK_RES_MEM_FLOOR 512000 //512 KB
> -#define CHUNK_RES_MEM_CEILING 1000000 // 1MB
>
> -#endif //HELIX_HTTPFSYS_MEM_GROWTH_LIMIT
>
> typedef enum
> {
> Index: helix-client-OLPC.pf
> ===================================================================
> RCS file: /cvsroot/ribosome/build/umakepf/helix-client-OLPC.pf,v
> retrieving revision 1.1
> diff -u -w -r1.1 helix-client-OLPC.pf
> --- helix-client-OLPC.pf 29 Mar 2007 20:58:17 -0000 1.1
> +++ helix-client-OLPC.pf 31 Mar 2007 00:46:44 -0000
> @@ -95,3 +95,6 @@
>
> project.AddDefines('HELIX_FEATURE_HTTPFSYS_MEM_GROWTH_LIMIT')
> project.AddDefines('HELIX_FEATURE_ALSA')
> +
> +project.AddDefines("CHUNK_RES_MEM_FLOOR=128000")
> +project.AddDefines("CHUNK_RES_MEM_CEILING=256000")
>
> _______________________________________________
> Filesystem-dev mailing list
> Filesystem-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/filesystem-dev
From gwright at real.com Tue Apr 3 17:22:14 2007
From: gwright at real.com (Greg Wright)
Date: Tue Apr 3 17:52:16 2007
Subject: [Filesystem-dev] CN: Allow overrides of growth limits....
In-Reply-To: <4612B2B5.7030009@real.com>
References: <460DB01F.7060409@real.com> <4612B2B5.7030009@real.com>
Message-ID: <4612EFB6.8070402@real.com>
This is now checked into HEAD.
--greg.
Greg Wright wrote:
> I am going to go ahead and check this into HEAD today
> if I don't hear anything further....
>
> --greg.
>
>
> Greg Wright wrote:
>> We need to be able to change the floor and ceiling values depending
>> on the build target:
>>
>> #define CHUNK_RES_MEM_FLOOR 512000 //512 KB
>> #define CHUNK_RES_MEM_CEILING 1000000 // 1MB
>>
>> This change just uses the defaults only if they are not defined
>> already. Then I just define them in the OLPC profile as needed.
>>
>> After this change, HTTP streaming works on the XO (olpc) for SMIL,
>> RV, Ogg and other datatypes.
>>
>> HEAD only.
>>
>> --greg.
>>
>>
>>
>> Index: httpfsys.h
>> ===================================================================
>> RCS file: /cvsroot/filesystem/http/httpfsys.h,v
>> retrieving revision 1.38
>> diff -u -w -r1.38 httpfsys.h
>> --- httpfsys.h 8 Mar 2006 02:28:35 -0000 1.38
>> +++ httpfsys.h 31 Mar 2007 00:46:22 -0000
>> @@ -103,11 +103,16 @@
>> #define DEFAULT_CHUNK_SIZE 1024 //default size of chunk buffer
>>
>> #ifdef HELIX_FEATURE_HTTPFSYS_MEM_GROWTH_LIMIT
>> +# if !defined(CHUNK_RES_MEM_FLOOR)
>> +# define CHUNK_RES_MEM_FLOOR 512000
>> +# endif
>> +# if !defined(CHUNK_RES_MEM_CEILING)
>> +# define CHUNK_RES_MEM_CEILING 1000000
>> +# endif
>> +#endif //HELIX_HTTPFSYS_MEM_GROWTH_LIMIT
>> +
>>
>> -#define CHUNK_RES_MEM_FLOOR 512000 //512 KB
>> -#define CHUNK_RES_MEM_CEILING 1000000 // 1MB
>>
>> -#endif //HELIX_HTTPFSYS_MEM_GROWTH_LIMIT
>>
>> typedef enum
>> {
>> Index: helix-client-OLPC.pf
>> ===================================================================
>> RCS file: /cvsroot/ribosome/build/umakepf/helix-client-OLPC.pf,v
>> retrieving revision 1.1
>> diff -u -w -r1.1 helix-client-OLPC.pf
>> --- helix-client-OLPC.pf 29 Mar 2007 20:58:17 -0000 1.1
>> +++ helix-client-OLPC.pf 31 Mar 2007 00:46:44 -0000
>> @@ -95,3 +95,6 @@
>>
>> project.AddDefines('HELIX_FEATURE_HTTPFSYS_MEM_GROWTH_LIMIT')
>> project.AddDefines('HELIX_FEATURE_ALSA')
>> +
>> +project.AddDefines("CHUNK_RES_MEM_FLOOR=128000")
>> +project.AddDefines("CHUNK_RES_MEM_CEILING=256000")
>>
>> _______________________________________________
>> Filesystem-dev mailing list
>> Filesystem-dev@helixcommunity.org
>> http://lists.helixcommunity.org/mailman/listinfo/filesystem-dev
>
From plissken.s at gmail.com Tue Apr 3 19:50:49 2007
From: plissken.s at gmail.com (S Plissken)
Date: Tue Apr 3 20:20:54 2007
Subject: [Filesystem-dev] SYNCACCESS vs ASYNCACCESS
Message-ID: <70bb9d5d0704031950y51abe5e2if1b3573d13ec9ad7@mail.gmail.com>
Hi,
I have been looking at some datatype source code, and I notice the following
code:
I would like to know what is the difference between SYNCACCESS vs
ASYNCACCESS
And how can I configure to have SYNCACCESS instead of ASYNCACCES or vice
versa?
// Find out if syncrhonous use of input is possible
if (SUCCEEDED(retVal))
{
if (SUCCEEDED(m_pFileSwitcher->Advise(HX_FILEADVISE_SYNCACCESS)))
{
m_bSyncAccessEnabled = TRUE;
m_pFileSwitcher->Advise(HX_FILEADVISE_ASYNCACCESS);
}
HX_RESULT adviseRes =
m_pFileSwitcher->Advise(HX_FILEADVISE_RANDOMACCESS);
if (HXR_ADVISE_PREFER_LINEAR == adviseRes)
{
m_bPreferLinearAccess = TRUE;
}
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/filesystem-dev/attachments/20070403/639d17d0/attachment.html
From ehyche at real.com Wed Apr 4 06:04:02 2007
From: ehyche at real.com (Eric Hyche)
Date: Wed Apr 4 06:33:53 2007
Subject: [Filesystem-dev] SYNCACCESS vs ASYNCACCESS
In-Reply-To: <70bb9d5d0704031950y51abe5e2if1b3573d13ec9ad7@mail.gmail.com>
References: <70bb9d5d0704031950y51abe5e2if1b3573d13ec9ad7@mail.gmail.com>
Message-ID: <007101c776b9$b8befc60$db68a8c0@EHYCHED620>
You don't really "configure" the file object to
behave one way or another - usually that is determined by
the type of file object itself and a lot of other conditions.
The Advise method is there so that the file object can communicate
its behavior to whoever is using it.
For instance, a local filesystem can (*most* of the time)
respond synchronously, while the http filesystem may usually
respond asynchronously. If the user of the file object wants
to do some optimization based on whether the file object
is going to respond synchronously/asynchronously, then
the Advise method is where it gets that information.
Eric
=============================================
Eric Hyche (ehyche@real.com)
Technical Lead
RealNetworks, Inc.
> -----Original Message-----
> From: filesystem-dev-bounces@helixcommunity.org
> [mailto:filesystem-dev-bounces@helixcommunity.org] On Behalf
> Of S Plissken
> Sent: Tuesday, April 03, 2007 10:51 PM
> To: filesystem-dev@helixcommunity.org
> Subject: [Filesystem-dev] SYNCACCESS vs ASYNCACCESS
>
> Hi,
>
> I have been looking at some datatype source code, and I
> notice the following code:
> I would like to know what is the difference between
> SYNCACCESS vs ASYNCACCESS
> And how can I configure to have SYNCACCESS instead of
> ASYNCACCES or vice versa?
>
>
> // Find out if syncrhonous use of input is possible
> if (SUCCEEDED(retVal))
> {
> if (SUCCEEDED(m_pFileSwitcher->Advise(HX_FILEADVISE_SYNCACCESS)))
> {
> m_bSyncAccessEnabled = TRUE;
> m_pFileSwitcher->Advise(HX_FILEADVISE_ASYNCACCESS);
> }
>
> HX_RESULT adviseRes =
> m_pFileSwitcher->Advise(HX_FILEADVISE_RANDOMACCESS);
>
> if (HXR_ADVISE_PREFER_LINEAR == adviseRes)
> {
> m_bPreferLinearAccess = TRUE;
> }
> }
>
>
>
>
>
From ehyche at real.com Wed Apr 4 06:06:19 2007
From: ehyche at real.com (Eric Hyche)
Date: Wed Apr 4 06:36:10 2007
Subject: [Filesystem-dev] File Seek in the beginning of streaming
In-Reply-To:
References:
<00fa01c76be1$75bca760$db68a8c0@EHYCHED620>
<03c701c7754b$d4c86b90$db68a8c0@EHYCHED620>
Message-ID: <007201c776ba$0a4afe30$db68a8c0@EHYCHED620>
The best place to start is to set a breakpoint at the
beginning of the file format's IHXFileFormatObject::InitFileFormat(),
IHXFileFormatObject::GetFileHeader(), and
IHXFileFormatObject::GetStreamHeader()
methods. Then start the server and hit the server from
a client with a media type which will use the file format
you are interested in.
Eric
=============================================
Eric Hyche (ehyche@real.com)
Technical Lead
RealNetworks, Inc.
> -----Original Message-----
> From: ken carlino [mailto:ken.carlino@gmail.com]
> Sent: Tuesday, April 03, 2007 12:22 AM
> To: ehyche@real.com
> Cc: filesystem-dev@helixcommunity.org
> Subject: Re: [Filesystem-dev] File Seek in the beginning of streaming
>
> Thanks. Can you please tell me how can i just debug the file
> format plugin
> after I start Helix server?
>
> On 4/2/07, Eric Hyche wrote:
> >
> > Not sure off the top of my head. I would step through
> > the file format plugin in a debugger to be sure.
> > The .3gp file format is located in datatype/mp4/fileformat.
> >
> > Eric
> >
> > =============================================
> > Eric Hyche (ehyche@real.com)
> > Technical Lead
> > RealNetworks, Inc.
> >
> > > -----Original Message-----
> > > From: ken carlino [mailto:ken.carlino@gmail.com]
> > > Sent: Friday, March 23, 2007 10:05 PM
> > > To: ehyche@real.com
> > > Cc: filesystem-dev@helixcommunity.org
> > > Subject: Re: [Filesystem-dev] File Seek in the beginning
> of streaming
> > >
> > > On 3/21/07, Eric Hyche wrote:
> > > >
> > > > What kind of file is being streamed?
> > > >
> > > > Most likely this is a type of file that doesn't
> > > > have the necessary header information at the beginning
> > > > of the file (i.e. - mp3). Therefore, the file format
> > > > plugin has to seek to the end of the file to get
> > > > some information before going back and starting
> > > > to deliver packets.
> > > >
> > >
> > > Thanks. I am trying to stream 3gp.
> > >
> > > After reading your response, I use a tool from FFmpeg which
> > > moves moov atom
> > > to the front. But after I use this to convert the movie
> and use Helix
> > > to stream,
> > > i still see Helix to seek to the end of the move before
> seek back to
> > > the top of the movie and start streaming.
> > >
> > > Can you please help me understand why helix still needs
> to seek to the
> > > end of the move?
> > >
> > > Thank you.
> > >
> > >
> > > // Details of the qt-faststart:
> > >
> > > * This utility rearranges a Quicktime file such that the
> moov atom
> > > * is in front of the data, thus facilitating network streaming.
> > > *
> > > * Compile this program using:
> > > * make qt-faststart
> > > * Invoke the program with:
> > > * qt-faststart
> > > *
> > > * Notes: Quicktime files can come in many configurations
> of top-level
> > > * atoms. This utility stipulates that the very last atom in
> > > the file needs
> > > * to be a moov atom. When given such a file, this utility
> > > will rearrange
> > > * the top-level atoms by shifting the moov atom from the
> > > back of the file
> > > * to the front, and patch the chunk offsets along the way.
> > > This utility
> > > * presently only operates on uncompressed moov atoms.
> > >
> > >
> > >
> > > > Eric
> > > >
> > > > =============================================
> > > > Eric Hyche (ehyche@real.com)
> > > > Technical Lead
> > > > RealNetworks, Inc.
> > > >
> > > > > -----Original Message-----
> > > > > From: filesystem-dev-bounces@helixcommunity.org
> > > > > [mailto:filesystem-dev-bounces@helixcommunity.org] On Behalf
> > > > > Of ken carlino
> > > > > Sent: Wednesday, March 21, 2007 12:32 PM
> > > > > To: filesystem-dev@helixcommunity.org
> > > > > Subject: [Filesystem-dev] File Seek in the beginning
> of streaming
> > > > >
> > > > > Hi,
> > > > > I am trying to study the behavior of FileStream in the
> > > beginning of
> > > > > streaming in Helix.
> > > > > I notice that Helix first tries to seek to end of the
> > > file, read 4K
> > > > > off the file and then re-seek the file to the
> beginning and start
> > > > > streaming from there.
> > > > >
> > > > > My question is why it seeks to the end of the file in the
> > > beginning?
> > > > >
> > > > > Thank you.
> > > > >
> > > > > _______________________________________________
> > > > > Filesystem-dev mailing list
> > > > > Filesystem-dev@helixcommunity.org
> > > > >
> http://lists.helixcommunity.org/mailman/listinfo/filesystem-dev
> > > > >
> > > >
> > > >
> > >
> >
> >
>
From ken.carlino at gmail.com Wed Apr 4 12:43:08 2007
From: ken.carlino at gmail.com (ken carlino)
Date: Wed Apr 4 13:12:59 2007
Subject: [Filesystem-dev] File Seek in the beginning of streaming
In-Reply-To: <007201c776ba$0a4afe30$db68a8c0@EHYCHED620>
References:
<00fa01c76be1$75bca760$db68a8c0@EHYCHED620>
<03c701c7754b$d4c86b90$db68a8c0@EHYCHED620>
<007201c776ba$0a4afe30$db68a8c0@EHYCHED620>
Message-ID:
Eric,
Thanks for your help.
I find out that in the function CQTFileFormat::GetFileHeader(), it
calls 'Atomize()'.
This is where Helix seek to the end of the file before it start
streaming a mp4 file.
But I still can't figure out why Atomize() does it (seek to the end of
the file).
On 4/4/07, Eric Hyche wrote:
>
> The best place to start is to set a breakpoint at the
> beginning of the file format's IHXFileFormatObject::InitFileFormat(),
> IHXFileFormatObject::GetFileHeader(), and
> IHXFileFormatObject::GetStreamHeader()
> methods. Then start the server and hit the server from
> a client with a media type which will use the file format
> you are interested in.
>
> Eric
>
> =============================================
> Eric Hyche (ehyche@real.com)
> Technical Lead
> RealNetworks, Inc.
>
> > -----Original Message-----
> > From: ken carlino [mailto:ken.carlino@gmail.com]
> > Sent: Tuesday, April 03, 2007 12:22 AM
> > To: ehyche@real.com
> > Cc: filesystem-dev@helixcommunity.org
> > Subject: Re: [Filesystem-dev] File Seek in the beginning of streaming
> >
> > Thanks. Can you please tell me how can i just debug the file
> > format plugin
> > after I start Helix server?
> >
> > On 4/2/07, Eric Hyche wrote:
> > >
> > > Not sure off the top of my head. I would step through
> > > the file format plugin in a debugger to be sure.
> > > The .3gp file format is located in datatype/mp4/fileformat.
> > >
> > > Eric
> > >
> > > =============================================
> > > Eric Hyche (ehyche@real.com)
> > > Technical Lead
> > > RealNetworks, Inc.
> > >
> > > > -----Original Message-----
> > > > From: ken carlino [mailto:ken.carlino@gmail.com]
> > > > Sent: Friday, March 23, 2007 10:05 PM
> > > > To: ehyche@real.com
> > > > Cc: filesystem-dev@helixcommunity.org
> > > > Subject: Re: [Filesystem-dev] File Seek in the beginning
> > of streaming
> > > >
> > > > On 3/21/07, Eric Hyche wrote:
> > > > >
> > > > > What kind of file is being streamed?
> > > > >
> > > > > Most likely this is a type of file that doesn't
> > > > > have the necessary header information at the beginning
> > > > > of the file (i.e. - mp3). Therefore, the file format
> > > > > plugin has to seek to the end of the file to get
> > > > > some information before going back and starting
> > > > > to deliver packets.
> > > > >
> > > >
> > > > Thanks. I am trying to stream 3gp.
> > > >
> > > > After reading your response, I use a tool from FFmpeg which
> > > > moves moov atom
> > > > to the front. But after I use this to convert the movie
> > and use Helix
> > > > to stream,
> > > > i still see Helix to seek to the end of the move before
> > seek back to
> > > > the top of the movie and start streaming.
> > > >
> > > > Can you please help me understand why helix still needs
> > to seek to the
> > > > end of the move?
> > > >
> > > > Thank you.
> > > >
> > > >
> > > > // Details of the qt-faststart:
> > > >
> > > > * This utility rearranges a Quicktime file such that the
> > moov atom
> > > > * is in front of the data, thus facilitating network streaming.
> > > > *
> > > > * Compile this program using:
> > > > * make qt-faststart
> > > > * Invoke the program with:
> > > > * qt-faststart
> > > > *
> > > > * Notes: Quicktime files can come in many configurations
> > of top-level
> > > > * atoms. This utility stipulates that the very last atom in
> > > > the file needs
> > > > * to be a moov atom. When given such a file, this utility
> > > > will rearrange
> > > > * the top-level atoms by shifting the moov atom from the
> > > > back of the file
> > > > * to the front, and patch the chunk offsets along the way.
> > > > This utility
> > > > * presently only operates on uncompressed moov atoms.
> > > >
> > > >
> > > >
> > > > > Eric
> > > > >
> > > > > =============================================
> > > > > Eric Hyche (ehyche@real.com)
> > > > > Technical Lead
> > > > > RealNetworks, Inc.
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: filesystem-dev-bounces@helixcommunity.org
> > > > > > [mailto:filesystem-dev-bounces@helixcommunity.org] On Behalf
> > > > > > Of ken carlino
> > > > > > Sent: Wednesday, March 21, 2007 12:32 PM
> > > > > > To: filesystem-dev@helixcommunity.org
> > > > > > Subject: [Filesystem-dev] File Seek in the beginning
> > of streaming
> > > > > >
> > > > > > Hi,
> > > > > > I am trying to study the behavior of FileStream in the
> > > > beginning of
> > > > > > streaming in Helix.
> > > > > > I notice that Helix first tries to seek to end of the
> > > > file, read 4K
> > > > > > off the file and then re-seek the file to the
> > beginning and start
> > > > > > streaming from there.
> > > > > >
> > > > > > My question is why it seeks to the end of the file in the
> > > > beginning?
> > > > > >
> > > > > > Thank you.
> > > > > >
> > > > > > _______________________________________________
> > > > > > Filesystem-dev mailing list
> > > > > > Filesystem-dev@helixcommunity.org
> > > > > >
> > http://lists.helixcommunity.org/mailman/listinfo/filesystem-dev
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>
From Arnel.Periquet at nokia.com Tue Apr 17 15:42:25 2007
From: Arnel.Periquet at nokia.com (Arnel.Periquet@nokia.com)
Date: Tue Apr 17 16:10:40 2007
Subject: [Clientapps-dev] [Filesystem-dev] CR: More Integration BUG fixes for
Series 60 Progressive Download
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
? Makefile
? MmfCtrlLib.mak
? MmfCtrlLib.upp
? Umakefil.upp
? clientapps_symbianMmf_diff.txt
? winscw-dbg32
? audiocontroller/Makefile
? audiocontroller/Umakefil.upp
? audiocontroller/controllerdll.mak
? audiocontroller/controllerdll.upp
? audiocontroller/controllersis.mak
? audiocontroller/controllersis.upp
? audiocontroller/copyDlls.bat
? audiocontroller/hxaudio-s60-mmf.pkg
? audiocontroller/hxaudio-s60-mmf.sis
? audiocontroller/hxmmfaudioctrl.uid.cpp
? audiocontroller/winscw-dbg32
? common/Makefile
? common/Umakefil.upp
? common/winscw-dbg32
? videocontroller/Makefile
? videocontroller/MmfCtrlDll.mak
? videocontroller/MmfCtrlDll.upp
? videocontroller/MmfSis.mak
? videocontroller/MmfSis.upp
? videocontroller/Umakefil.upp
? videocontroller/copyDlls.bat
? videocontroller/hxmmfctrl.uid.cpp
? videocontroller/mmfplayer-s60-mmf.pkg
? videocontroller/mmfplayer-s60-mmf.sis
? videocontroller/winscw-dbg32
Index: common/hxmmfbasectrl.cpp
===================================================================
RCS file: /cvsroot/clientapps/symbianMmf/common/hxmmfbasectrl.cpp,v
retrieving revision 1.1.2.16
diff -u -b -r1.1.2.16 hxmmfbasectrl.cpp
--- common/hxmmfbasectrl.cpp 13 Apr 2007 23:28:24 -0000 1.1.2.16
+++ common/hxmmfbasectrl.cpp 17 Apr 2007 21:27:37 -0000
@@ -141,8 +141,8 @@
{ HXR_CLOSED, KErrSessionClosed },
{ HXR_SOCK_DISCON, KErrDisconnected },
{ HXR_CORRUPT_FILE, KErrCorrupt },
- { HXR_PROGRESSIVE_DOWNLOAD_TIMEOUT, KErrTimedOut },
- { HXR_FULL_DOWNLOAD_NEEDED, KErrTimedOut },
+ { HXR_PROGRESSIVE_DOWNLOAD_TIMEOUT, KErrEof },
+ { HXR_FULL_DOWNLOAD_NEEDED, KErrAbort },
{ HXR_ACCESSPOINT_NOT_FOUND, KErrAbort },
{ HXR_PE_INTERNAL_SERVER_ERROR, KErrDisconnected },
{ HXR_NOT_AUTHORIZED, KErrPermissionDenied },
-------------- next part --------------
? Makefile
? Umakefil.upp
? filesystem_local_diff.txt
? smplfsys.def
? smplfsys.uid.cpp
? smplfsys_dll_stub.c
? smplfsys_ordinal.dat
? winscw-dbg32
Index: mini/minifileobj.cpp
===================================================================
RCS file: /cvsroot/filesystem/local/mini/minifileobj.cpp,v
retrieving revision 1.23.2.1
diff -u -b -r1.23.2.1 minifileobj.cpp
--- mini/minifileobj.cpp 24 Aug 2006 20:15:01 -0000 1.23.2.1
+++ mini/minifileobj.cpp 17 Apr 2007 21:29:12 -0000
@@ -641,6 +641,7 @@
if (m_pFile && ferror(m_pFile))
{
+ HX_RELEASE(pBuffer);
ReadDoneError(HXR_READ_ERROR);
return HXR_READ_ERROR;
}
@@ -732,11 +733,10 @@
if (pErrMsg)
{
- pErrMsg->AddRef();
pErrMsg->Report(HXLOG_ERR, theError, 0, NULL , NULL);
+ HX_RELEASE(pErrMsg);
}
- HX_RELEASE(pErrMsg);
m_pFileResponse->ReadDone(theError, NULL);
}
-------------- next part --------------
? Makefile
? Umakefil.upp
? filesystem_progdown_diff.txt
? progdownfs.def
? progdownfs.uid.cpp
? progdownfs_dll_stub.c
? progdownfs_ordinal.dat
? winscw-dbg32
Index: platform/symbian/pdfileobj.cpp
===================================================================
RCS file: /cvsroot/filesystem/progdown/platform/symbian/pdfileobj.cpp,v
retrieving revision 1.1.1.1.2.3
diff -u -b -r1.1.1.1.2.3 pdfileobj.cpp
--- platform/symbian/pdfileobj.cpp 27 Mar 2007 15:07:23 -0000 1.1.1.1.2.3
+++ platform/symbian/pdfileobj.cpp 17 Apr 2007 21:31:54 -0000
@@ -198,7 +198,7 @@
UINT32 actualCount = 0;
- if(m_ulByteOffset <= ulFileSize-byteCount)
+ if(m_ulByteOffset + byteCount <= ulFileSize)
{
actualCount = DoRead(pBuffer);
}
@@ -237,6 +237,7 @@
}
else
{
+ HX_RELEASE(pBuffer);
ReadDoneError(HXR_PROGRESSIVE_DOWNLOAD_TIMEOUT);
result = HXR_PROGRESSIVE_DOWNLOAD_TIMEOUT;
}
@@ -419,7 +420,7 @@
UINT32 actualCount = 0;
- if(m_ulByteOffset <= ulFileSize-m_ulRetryByteCount)
+ if(m_ulByteOffset + m_ulRetryByteCount <= ulFileSize )
{
actualCount = DoRead(m_pRetryReadBuffer);
}
@@ -444,6 +445,7 @@
{
HXLOGL2(HXLOG_FILE,
"CHXPDFileObject::RetryRead() timeout waiting for more data");
+ HX_RELEASE(m_pRetryReadBuffer);
ReadDoneError(HXR_PROGRESSIVE_DOWNLOAD_TIMEOUT);
}
else
From ehyche at real.com Wed Apr 18 05:47:42 2007
From: ehyche at real.com (Eric Hyche)
Date: Wed Apr 18 06:14:06 2007
Subject: [Clientapps-dev] [Filesystem-dev] CR: More Integration BUG fixes
forSeries 60 Progressive Download
In-Reply-To:
References:
Message-ID: <003d01c781b7$c269cb60$db68a8c0@EHYCHED620>
Looks good.
=============================================
Eric Hyche (ehyche@real.com)
Technical Lead
RealNetworks, Inc.
> -----Original Message-----
> From: filesystem-dev-bounces@helixcommunity.org
> [mailto:filesystem-dev-bounces@helixcommunity.org] On Behalf
> Of Arnel.Periquet@nokia.com
> Sent: Tuesday, April 17, 2007 6:42 PM
> To: clientapps-dev@helixcommunity.org;
> filesystem-dev@helixcommunity.org
> Subject: [Clientapps-dev] [Filesystem-dev] CR: More
> Integration BUG fixes forSeries 60 Progressive Download
>
> "Nokia submits this code under the terms of a commercial
> contribution agreement with RealNetworks, and I am authorized
> to contribute this code under said agreement."
>
> Modified by: Arnel.Periquet@nokia.com
>
> Reviewed by:
>
> Date: 04-17-2007
>
> Project: Helix Symbian Plugin
>
> ErrorId: T.B.D.
>
> Synopsis: More Integration BUG fixes for Series 60
> Progressive Download
>
> Previously, a feature was submitted for "Progressive Download
> Filesystem Plugin for Series 60". This CR fixes the following
> problems associated with that feature:
>
> (1) Memory leaks: In the case where a file is determined to
> be non-progressively downloadable (non-PDL), i.e. it must be
> completely downloaded before it can be played, the
> progressive download file system reports an error via the
> ReadDoneError() method on CHXMiniFileObject
> (minifileobject.cpp). Two leaks have been identified in
> relation to this scenario. First, a redundant AddRef() is
> performed on the IHXErrorMessages object. Second, in places
> where ReadDoneError() is called, the allocated read buffer is
> not being deallocated. The first leak is removed by removing
> the redundant AddRef() call. The second is resolved by
> deallocating the read buffer in all places where
> ReadDoneError() is called.
>
> (2) Error Code for Non-PDL files: In the case of a non-PDL
> file, the Helix engine must return an error code to the TLC.
> That error code should uniquely identify the error condition.
> For S60 progressive download, the local filesystem is used
> for playback. So, KErrAbort will be used to uniquely identify
> the non-PDL case.
>
> (3) Error Code for timeout reading a PDL file: In the case of
> a timeout reading a PDL file, the Helix engine must return an
> error code to the TLC. That error code should uniquely
> identify the error condition. For S60 progressive download,
> KErrEof will be used to uniquely identify a timeout on read error.
>
> Root Cause: These problems were revealed during integration
> testing. Module-level testing did not reveal the problems.
>
> Files Modified:
> hxmmfbasectrl.cpp - error codes modified
> minifileobj.cpp - memory leaks removed
> pdfileobj.cpp - memory leaks removed
>
> Image Size and Heap Use Impact: no major impact
>
> Module Release Testing (STIF): All local cases pass.
>
> Test Case(s) Added: Manual testing required for memory leak
> testing--case (1). New STIF cases are planned for cases (2) and (3).
>
> Memory Leak Check Performed: Yes. No new leaks introduced.
> Two existing leaks removed.
>
> Platforms and Profiles Build Verified: helix-client-s60-mmf-mdf-dsp
>
> Platforms and Profiles Functionality Verified: armv5, winscw
>
> Branch: Head & 210CayS
>
>
> <>
> <> <>
>
>
From Arnel.Periquet at nokia.com Wed Apr 18 11:06:14 2007
From: Arnel.Periquet at nokia.com (Arnel.Periquet@nokia.com)
Date: Wed Apr 18 11:32:47 2007
Subject: [Clientapps-dev] [Filesystem-dev] CN: More Integration BUG fixes
forSeries 60 Progressive Download
In-Reply-To: <003d01c781b7$c269cb60$db68a8c0@EHYCHED620>
References:
<003d01c781b7$c269cb60$db68a8c0@EHYCHED620>
Message-ID:
Checked into HEAD and CAY210S.
Thanks,
Arnel
>-----Original Message-----
>From: ext Eric Hyche [mailto:ehyche@real.com]
>Sent: Wednesday, April 18, 2007 7:48 AM
>To: Periquet Arnel (Nokia-TP-MSW/Dallas);
>clientapps-dev@helixcommunity.org; filesystem-dev@helixcommunity.org
>Subject: RE: [Clientapps-dev] [Filesystem-dev] CR: More
>Integration BUG fixes forSeries 60 Progressive Download
>
>
>Looks good.
>
>=============================================
>Eric Hyche (ehyche@real.com)
>Technical Lead
>RealNetworks, Inc.
>
>> -----Original Message-----
>> From: filesystem-dev-bounces@helixcommunity.org
>> [mailto:filesystem-dev-bounces@helixcommunity.org] On Behalf Of
>> Arnel.Periquet@nokia.com
>> Sent: Tuesday, April 17, 2007 6:42 PM
>> To: clientapps-dev@helixcommunity.org;
>> filesystem-dev@helixcommunity.org
>> Subject: [Clientapps-dev] [Filesystem-dev] CR: More Integration BUG
>> fixes forSeries 60 Progressive Download
>>
>> "Nokia submits this code under the terms of a commercial
>contribution
>> agreement with RealNetworks, and I am authorized to contribute this
>> code under said agreement."
>>
>> Modified by: Arnel.Periquet@nokia.com
>>
>> Reviewed by:
>>
>> Date: 04-17-2007
>>
>> Project: Helix Symbian Plugin
>>
>> ErrorId: APET-72DKTX
>>
>> Synopsis: More Integration BUG fixes for Series 60 Progressive
>> Download
>>
>> Previously, a feature was submitted for "Progressive Download
>> Filesystem Plugin for Series 60". This CR fixes the
>following problems
>> associated with that feature:
>>
>> (1) Memory leaks: In the case where a file is determined to be
>> non-progressively downloadable (non-PDL), i.e. it must be completely
>> downloaded before it can be played, the progressive download file
>> system reports an error via the
>> ReadDoneError() method on CHXMiniFileObject
>(minifileobject.cpp). Two
>> leaks have been identified in relation to this scenario. First, a
>> redundant AddRef() is performed on the IHXErrorMessages object.
>> Second, in places where ReadDoneError() is called, the
>allocated read
>> buffer is not being deallocated. The first leak is removed
>by removing
>> the redundant AddRef() call. The second is resolved by deallocating
>> the read buffer in all places where
>> ReadDoneError() is called.
>>
>> (2) Error Code for Non-PDL files: In the case of a non-PDL file, the
>> Helix engine must return an error code to the TLC.
>> That error code should uniquely identify the error condition.
>> For S60 progressive download, the local filesystem is used for
>> playback. So, KErrAbort will be used to uniquely identify
>the non-PDL
>> case.
>>
>> (3) Error Code for timeout reading a PDL file: In the case of a
>> timeout reading a PDL file, the Helix engine must return an
>error code
>> to the TLC. That error code should uniquely identify the error
>> condition. For S60 progressive download, KErrEof will be used to
>> uniquely identify a timeout on read error.
>>
>> Root Cause: These problems were revealed during integration testing.
>> Module-level testing did not reveal the problems.
>>
>> Files Modified:
>> hxmmfbasectrl.cpp - error codes modified
>> minifileobj.cpp - memory leaks removed
>> pdfileobj.cpp - memory leaks removed
>>
>> Image Size and Heap Use Impact: no major impact
>>
>> Module Release Testing (STIF): All local cases pass.
>>
>> Test Case(s) Added: Manual testing required for memory leak
>> testing--case (1). New STIF cases are planned for cases (2) and (3).
>>
>> Memory Leak Check Performed: Yes. No new leaks introduced.
>> Two existing leaks removed.
>>
>> Platforms and Profiles Build Verified: helix-client-s60-mmf-mdf-dsp
>>
>> Platforms and Profiles Functionality Verified: armv5, winscw
>>
>> Branch: Head & 210CayS
>>
>>
>> <>
>> <> <>
>>
>>
>
>
Copyright © 1995-2007 RealNetworks, Inc. All rights reserved.
RealNetworks and Helix are trademarks of RealNetworks.
All other trademarks or registered trademarks are the property of their respective holders.