[prev in list] [next in list] [prev in thread] [next in thread]
List: helix-datatype-dev
Subject: RE: [datatype-dev] Resend CR: It need several seconds to respond
From: Li Qing <lqing () real ! com>
Date: 2011-07-29 2:28:16
Message-ID: 4A242CD46F4C34418D17941FF9746F97747139218B () SEAMBX ! corp ! real ! com
[Download RAW message or body]
Thanks, Checked into 361, 310 and HEAD
Best Regards!
Li Qing
--
RealNetworks China, Beijing Office
Tel: 008601059542848
Fax: 008601085656477
Address: 18th Floor,Tower B,Pacific Century Place,2A GongTiBeiLu,Chaoyang \
District,Beijing, China Post Code: 100027
________________________________________
From: Sheldon Fu
Sent: Thursday, July 28, 2011 8:28 PM
To: Li Qing
Cc: datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] Resend CR: It need several seconds to respond when seek \
some wmv contents
ok.
fxd
On 07/28/2011 08:01 AM, Li Qing wrote:
> Hi, Sheldon,
> I fixed a bug which is injected from previous patch. Please help to review, thanks!
> Best Regards!
> Li Qing
> --
> RealNetworks China, Beijing Office
> Tel: 008601059542848
> Fax: 008601085656477
> Address: 18th Floor,Tower B,Pacific Century Place,2A GongTiBeiLu,Chaoyang \
> District,Beijing, China Post Code: 100027
> ________________________________________
> From: Li Qing
> Sent: Thursday, July 28, 2011 12:38 PM
> To: Sheldon Fu
> Cc: datatype-dev@helixcommunity.org
> Subject: RE: [datatype-dev] Resend CR: It need several seconds to respond when seek \
> some wmv contents
> Done, Thanks again!
> Best Regards!
> Li Qing
> --
> RealNetworks China, Beijing Office
> Tel: 008601059542848
> Fax: 008601085656477
> Address: 18th Floor,Tower B,Pacific Century Place,2A GongTiBeiLu,Chaoyang \
> District,Beijing, China Post Code: 100027
> ________________________________________
> From: Sheldon Fu
> Sent: Thursday, July 28, 2011 11:29 AM
> To: Li Qing
> Cc: datatype-dev@helixcommunity.org
> Subject: Re: [datatype-dev] Resend CR: It need several seconds to respond when seek \
> some wmv contents
> Sounds good.
>
> fxd
>
> On 07/27/2011 11:18 PM, Li Qing wrote:
> > Thank you, Sheldon. I suggest to check in previous version into 310 and HEAD \
> > branch (to fix the 'lost' packet issue), and check in this version into 361 \
> > branch, and merge the last version to 310 and HEAD after we test enough. OK? Best \
> > Regards! Li Qing
> > --
> > RealNetworks China, Beijing Office
> > Tel: 008601059542848
> > Fax: 008601085656477
> > Address: 18th Floor,Tower B,Pacific Century Place,2A GongTiBeiLu,Chaoyang \
> > District,Beijing, China Post Code: 100027
> > ________________________________________
> > From: Sheldon Fu
> > Sent: Wednesday, July 27, 2011 9:43 PM
> > To: Li Qing
> > Cc: datatype-dev@helixcommunity.org
> > Subject: Re: [datatype-dev] Resend CR: It need several seconds to respond when \
> > seek some wmv contents
> > Li Qing,
> >
> > This looks fine to me. This is a bigger change than last CR though so
> > there might be some risk. I am fine if you just use the last CR and be
> > safe. You call.
> >
> > fxd
> >
> > On 07/27/2011 09:23 AM, Li Qing wrote:
> > > Hi, Sheldon,
> > > According to your advice, I changed the patch again. In this version, I move \
> > > the m_bCheckPacketTime to class CHXStreamInfo, because we need to check all \
> > > streams after seek, and use m_ulCountForPacketTimeCheck to count how many \
> > > streams we didn't check, so that we can control when we should complete packet \
> > > time check. Moreover, because the packets could not be interleaved, so I added \
> > > the m_pTempQueueForPacketTimeCheck to cache the packets that from checked \
> > > stream. The others are almost as same as the previous version. Please help to \
> > > review again, thanks! Best Regards!
> > > Li Qing
> > > --
> > > RealNetworks China, Beijing Office
> > > Tel: 008601059542848
> > > Fax: 008601085656477
> > > Address: 18th Floor,Tower B,Pacific Century Place,2A GongTiBeiLu,Chaoyang \
> > > District,Beijing, China Post Code: 100027
> > > ________________________________________
> > > From: Li Qing
> > > Sent: Wednesday, July 27, 2011 1:32 PM
> > > To: Sheldon Fu
> > > Cc: datatype-dev@helixcommunity.org
> > > Subject: RE: [datatype-dev] Resend CR: It need several seconds to respond when \
> > > seek some wmv contents
> > > hmmmm, I think I misread your advice, it's a good idea! I will try to implement \
> > > it. Thanks a lot! Best Regards!
> > > Li Qing
> > > --
> > > RealNetworks China, Beijing Office
> > > Tel: 008601059542848
> > > Fax: 008601085656477
> > > Address: 18th Floor,Tower B,Pacific Century Place,2A GongTiBeiLu,Chaoyang \
> > > District,Beijing, China Post Code: 100027
> > > ________________________________________
> > > From: Sheldon Fu
> > > Sent: Wednesday, July 27, 2011 12:52 PM
> > > To: Li Qing
> > > Cc: datatype-dev@helixcommunity.org
> > > Subject: Re: [datatype-dev] Resend CR: It need several seconds to respond when \
> > > seek some wmv contents
> > > Li Qing,
> > >
> > > Good point but then the logic should simply be further improved by
> > > finding a video seek offset that is no later then audio seek offset.
> > > Without this check, we'll have to rely on the file to be properly
> > > interleaved to not seeing significant delay after seek. Not saying we
> > > need to do this now but just a thought.
> > >
> > > fxd
> > >
> > > On 07/26/2011 10:37 PM, Li Qing wrote:
> > > > Hi, Sheldon,
> > > > About the advice "...look at both and pick the one with the smaller file \
> > > > offset for seek target to ensure...", I think this might cause mosaic issue, \
> > > > because the video packet, which is followed to the audio packet which we \
> > > > picked, could not be a key frame, so we have to add more logic to ensure the \
> > > > first video packet (after-seek) be a key frame, but the time stamp of the key \
> > > > frame (packet) still could be later than the seek target, so I think we \
> > > > shouldn't change the old logic, but we should check the index type in \
> > > > CHXASFIndex::ImportIndexObject function, that is:
> > > > Index: asf_index.cpp
> > > > ===================================================================
> > > > RCS file: /cvsroot/datatype/wm/fileformat/asf_index.cpp,v
> > > > retrieving revision 1.2.12.1.18.3
> > > > diff -u -w -r1.2.12.1.18.3 asf_index.cpp
> > > > --- asf_index.cpp 19 Jul 2011 07:31:37 -0000 1.2.12.1.18.3
> > > > +++ asf_index.cpp 27 Jul 2011 02:27:30 -0000
> > > > @@ -330,6 +330,7 @@
> > > > ((UINT64) pBlock->m_pulOffset[ulEntryIndex + k]);
> > > > // Get the WM stream number
> > > > UINT16 usWMStreamNumber = pObj->m_pIndexSpecifier[k].m_usStreamNumber;
> > > > + UINT16 usWMIndexType = \
> > > > pObj->m_pIndexSpecifier[k].m_usIndexType; // Compute the presentation time. \
> > > > We don't know really // know the time that this entry represents (this \
> > > > information // is not in the Index Object), but we do know the range that
> > > > @@ -352,7 +353,9 @@
> > > > }
> > > > // Now enter this value into the on-the-fly table
> > > > // Invalid index enrties are indicated by 0xffffffff
> > > > + // According to the spec., the index type 3 = \
> > > > 'Nearest Past Cleanpoint', + // that point to a key \
> > > > frame.
> > > > - if(pBlock->m_pulOffset[ulEntryIndex + k] != \
> > > > 0xFFFFFFFF) + if(pBlock->m_pulOffset[ulEntryIndex + k] \
> > > > != 0xFFFFFFFF&& 3 == usWMIndexType) {
> > > > retVal = SetIndexEntry(usWMStreamNumber, ulPresTime,ullFileOffset);
> > > > }
> > > > Best Regards!
> > > > Li Qing
> > > > --
> > > > RealNetworks China, Beijing Office
> > > > Tel: 008601059542848
> > > > Fax: 008601085656477
> > > > Address: 18th Floor,Tower B,Pacific Century Place,2A GongTiBeiLu,Chaoyang \
> > > > District,Beijing, China Post Code: 100027
> > > > ________________________________________
> > > > From: Sheldon Fu
> > > > Sent: Wednesday, July 27, 2011 5:36 AM
> > > > To: Li Qing
> > > > Cc: datatype-dev@helixcommunity.org
> > > > Subject: Re: [datatype-dev] Resend CR: It need several seconds to respond \
> > > > when seek some wmv contents
> > > > Ok. it will be more appropriate to name it
> > > > m_uWMStreamNumForIndexTableLookup then since you don't really use it
> > > > control which stream to check for ts but just use it to look up previous
> > > > offset. Otherwise looks good.
> > > >
> > > > Ideally the seeking logic should be that in case there are seek tables
> > > > for both video and audio, we look at both and pick the one with the
> > > > smaller file offset for seek target to ensure that we always get packets
> > > > in *both* streams to be earlier than seek target. With proper
> > > > interleaved file this may not be too big a deal though.
> > > >
> > > > fxd
> > > >
> > > > On 07/26/2011 01:06 PM, Li Qing wrote:
> > > > > The m_uWMStreamNumForPacketTimeCheck is used to ensure we will look up in \
> > > > > the same index table (if there are more than one index tables) which we got \
> > > > > the value of the m_ullSeekOffsetRequested (from SearchIndexTable function) \
> > > > > before, because the video index table's file offset values could be very \
> > > > > different with the audio index table's, and it could cause we seek backward \
> > > > > to a wrong position if we don't store the correct WMStream number. Best \
> > > > > Regards! Li Qing
> > > > > --
> > > > > RealNetworks China, Beijing Office
> > > > > Tel: 008601059542848
> > > > > Fax: 008601085656477
> > > > > Address: 18th Floor,Tower B,Pacific Century Place,2A GongTiBeiLu,Chaoyang \
> > > > > District,Beijing, China Post Code: 100027
> > > > > ________________________________________
> > > > > From: Sheldon Fu
> > > > > Sent: Tuesday, July 26, 2011 8:54 PM
> > > > > To: Li Qing
> > > > > Cc: datatype-dev@helixcommunity.org
> > > > > Subject: Re: [datatype-dev] Resend CR: It need several seconds to respond \
> > > > > when seek some wmv contents
> > > > > what is m_uWMStreamNumForPacketTimeCheck used for then? It is assigned
> > > > > the video stream number when video stream is present, right?
> > > > >
> > > > > Packet time check should be for first after-seek packet from any stream.
> > > > > If you want a variable to remember what stream is used for seek table
> > > > > lookup, then this is not an appropriate name.
> > > > >
> > > > > fxd
> > > > >
> > > > > On 07/26/2011 02:40 AM, Li Qing wrote:
> > > > > > Hi, Sheldon,
> > > > > > About the root cause, you are right, but why do you think we only single \
> > > > > > out the video stream for the check? If you are talking about the \
> > > > > > SearchIndexTable function, the logic is that we just select the index \
> > > > > > entry of video stream as a priority (it invokes \
> > > > > > m_pASFIndex->LookupIndexEntry() in a 'for' loop), and in my patches (for \
> > > > > > this issue), I think there isn't any logic only against video stream. \
> > > > > > Best Regards! Li Qing
> > > > > > --
> > > > > > RealNetworks China, Beijing Office
> > > > > > Tel: 008601059542848
> > > > > > Fax: 008601085656477
> > > > > > Address: 18th Floor,Tower B,Pacific Century Place,2A GongTiBeiLu,Chaoyang \
> > > > > > District,Beijing, China Post Code: 100027
> > > > > > ________________________________________
> > > > > > From: Sheldon Fu
> > > > > > Sent: Tuesday, July 26, 2011 1:45 PM
> > > > > > To: Li Qing
> > > > > > Cc: datatype-dev@helixcommunity.org
> > > > > > Subject: Re: [datatype-dev] Resend CR: It need several seconds to respond \
> > > > > > when seek some wmv contents
> > > > > > Not sure why we single out the video stream for the check. The root
> > > > > > issue for this bug is that some buggy seek table can have entry pointing
> > > > > > to a file location with packets later than seek target, right? If this
> > > > > > is so then even an audio only clip can have the problem, isn't it?
> > > > > >
> > > > > > The correct logic seems should be that for *all* streams, the first
> > > > > > after-seek packet of that stream should have a timestamp no later than
> > > > > > the seek target.
> > > > > >
> > > > > > fxd
> > > > > >
> > > > > > On 07/25/2011 11:42 PM, Li Qing wrote:
> > > > > > > Modified by: lqing@real.com
> > > > > > > Date: 07/22/2011
> > > > > > > Project: RealPlayer for Android Smartphones
> > > > > > > Suggested Reviewer: Sheldon Fu
> > > > > > >
> > > > > > > Synopsis: It need several seconds to respond when seek some wmv \
> > > > > > > contents
> > > > > > > Overview: This is follow-up CR for a same issue (refer \
> > > > > > > http://lists.helixcommunity.org/pipermail/datatype-dev/2011-July/011023.html). \
> > > > > > > For some special test contents which index table is wrong, the first \
> > > > > > > packet, that after seeking, might be 'lost' packet, so we should skip \
> > > > > > > this 'lost' packet. Because the next packet's stream number might be \
> > > > > > > different, so I add a member variable m_uWMStreamNumForPacketTimeCheck \
> > > > > > > to store the original WMStream number.
> > > > > > > Files Added: None
> > > > > > >
> > > > > > > Files Modified:
> > > > > > > datatype/wm/fileformat/asf_file_format_file.cpp
> > > > > > > datatype/wm/fileformat/asf_file_format_file.h
> > > > > > > datatype/wm/fileformat/asf_index.cpp
> > > > > > >
> > > > > > > Image Size and Heap Use impact (Client -Only): None
> > > > > > >
> > > > > > > Platforms and Profiles Affected:
> > > > > > > Platform: android-2.3-arm-qsd_8x55
> > > > > > > Profile: helix-client-android-full
> > > > > > >
> > > > > > > Distribution Libraries Affected:None
> > > > > > >
> > > > > > > Distribution library impact and planned action:None
> > > > > > >
> > > > > > > Platforms and Profiles Build Verified:
> > > > > > > Platform: android-2.3-arm-qsd_8x55
> > > > > > > Profile: helix-client-android-full
> > > > > > >
> > > > > > > Platforms and Profiles Functionality verified:
> > > > > > > Platform: android-2.3-arm-qsd_8x55
> > > > > > > Profile: helix-client-android-full
> > > > > > >
> > > > > > > Branch: 361atlas, 310atlas, HEAD
> > > > > > >
> > > > > > > Copyright assignment: I am a RealNetworks employee or contractor
> > > > > > >
> > > > > > > Best Regards!
> > > > > > > Li Qing
> > > > > > > --
> > > > > > > RealNetworks China, Beijing Office
> > > > > > > Tel: 008601059542848
> > > > > > > Fax: 008601085656477
> > > > > > > Address: 18th Floor,Tower B,Pacific Century Place,2A \
> > > > > > > GongTiBeiLu,Chaoyang District,Beijing, China Post Code: 100027
> > > > > > .
> > > > > > .
> > > > .
> > > >
> > .
> >
_______________________________________________
Datatype-dev mailing list
Datatype-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic