|
List Info
Thread: CR-Client: fix FLV playback for odd 1-byte FLV packets
|
|
| CR-Client: fix FLV playback for odd
1-byte FLV packets |
 
United States |
2007-08-28 14:33:50 |
[I'm going to go ahead and check this in on
the 203Cay branch so Rhapsody QA can regress
the associated bug. I'll wait on the rest of
the branches until I hear back...]
Description
---------------------------------------
Previously I have never run across any FLV files that
had FLV packets with packet data sizes less than 2 bytes.
That's because the 1st byte of data is always a header, so
only having 1 byte of FLV packet data would essentially
mean you had NO data - a NULL packet.
However, during Rhapsody testing the Rhapsody QA team
ran across some FLV files like this. The current FLV
fileformat failed to read these files. This fix
corrects this, essentially skipping those FLV packets
which only have 1 data byte.
Files Modified
---------------------------------------
datatype/flash/flv/fileformat/flv_file_format.cpp
Branches
---------------------------------------
HEAD, 150Cay, 203Cay, 204Cay, 310Atlas
Index: flv_file_format.cpp
============================================================
=======
RCS file:
/cvsroot/datatype/flash/flv/fileformat/flv_file_format.cpp,v
retrieving revision 1.6.2.1.2.1.6.3
diff -u -w -r1.6.2.1.2.1.6.3 flv_file_format.cpp
--- flv_file_format.cpp 22 Aug 2007 18:08:07 -0000
1.6.2.1.2.1.6.3
+++ flv_file_format.cpp 28 Aug 2007 19:27:55 -0000
 -1179,8
+1179,35
m_ulState =
kStateGPTagReadDonePending;
// Save the number of read
bytes requested
m_ulReadBytesRequested =
m_cTagHeader.GetDataSize() - 1;
+ // In some rare FLV files, the
data size of an FLV
+ // packet can be 1. If we hit
one of these packets,
+ // then we don't need to read
any of the rest of the
+ // packet body, but rather go
straight on to reading
+ // the next FLV packet.
+ //
+ // Do we have more bytes to
read for this FLV packet?
+ if (m_ulReadBytesRequested)
+ {
// Read the rest of the tag
-
m_pFileObject->Read(m_cTagHeader.GetDataSize() - 1);
+
m_pFileObject->Read(m_ulReadBytesRequested);
+ }
+ else
+ {
+ // This is one of those
strange 1-byte FLV packets,
+ // so we don't really have
any data to provide for
+ // this packet, so go on to
read the next FLV packet.
+ //
+ // Set the state
+ m_ulState =
kStateGPReadDonePending;
+ // Save the number of read
bytes requested
+ m_ulReadBytesRequested =
HX_FLV_TAG_HEADER_SIZE + 1;
+ // Read an FLV tag header.
We read one more byte
+ // since for audio and
video packets, the first byte
+ // after the tag header is
packet info. For meta packets,
+ // there is no such byte,
but we are skipping meta packets
+ // since we read them
earlier in the GetFileHeader() call.
+
m_pFileObject->Read(m_ulReadBytesRequested);
+ }
}
}
}
=====================================
Eric Hyche, Technical Lead
RealNetworks, Inc.
ehychereal.com
_______________________________________________
Datatype-dev mailing list
Datatype-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/da
tatype-dev
|
|
| RE: CR-Client: fix FLV playback for odd
1-byte FLVpackets |
United States |
2007-08-28 16:10:30 |
Looks good.
Henry
> -----Original Message-----
> From: datatype-dev-bounceshelixcommunity.org
> [mailto:datatype-dev-bounceshelixcommunity.org] On
Behalf Of
> Eric Hyche
> Sent: Tuesday, August 28, 2007 12:34 PM Ping
> To: datatype-devlists.helixcommunity.org
> Subject: [datatype-dev] CR-Client: fix FLV playback for
odd
> 1-byte FLVpackets
>
>
> [I'm going to go ahead and check this in on the 203Cay
branch
> so Rhapsody QA can regress the associated bug. I'll
wait on
> the rest of the branches until I hear back...]
>
> Description
> ---------------------------------------
> Previously I have never run across any FLV files that
had FLV
> packets with packet data sizes less than 2 bytes.
> That's because the 1st byte of data is always a header,
so
> only having 1 byte of FLV packet data would essentially
mean
> you had NO data - a NULL packet.
>
> However, during Rhapsody testing the Rhapsody QA team
ran
> across some FLV files like this. The current FLV
fileformat
> failed to read these files. This fix corrects this,
> essentially skipping those FLV packets which only have
1 data byte.
>
> Files Modified
> ---------------------------------------
> datatype/flash/flv/fileformat/flv_file_format.cpp
>
> Branches
> ---------------------------------------
> HEAD, 150Cay, 203Cay, 204Cay, 310Atlas
>
> Index: flv_file_format.cpp
>
============================================================
=======
> RCS file:
/cvsroot/datatype/flash/flv/fileformat/flv_file_format.cpp,v
> retrieving revision 1.6.2.1.2.1.6.3
> diff -u -w -r1.6.2.1.2.1.6.3 flv_file_format.cpp
> --- flv_file_format.cpp 22 Aug 2007 18:08:07 -0000
> 1.6.2.1.2.1.6.3
> +++ flv_file_format.cpp 28 Aug 2007 19:27:55 -0000
> -1179,8 +1179,35
> m_ulState =
kStateGPTagReadDonePending;
> // Save the number of read
bytes
> requested
> m_ulReadBytesRequested =
> m_cTagHeader.GetDataSize() - 1;
> + // In some rare FLV files,
the
> data size of an FLV
> + // packet can be 1. If we
hit
> one of these packets,
> + // then we don't need to
read
> any of the rest of the
> + // packet body, but rather
go
> straight on to reading
> + // the next FLV packet.
> + //
> + // Do we have more bytes
to read
> for this FLV packet?
> + if
(m_ulReadBytesRequested)
> + {
> // Read the rest of the
tag
> -
> m_pFileObject->Read(m_cTagHeader.GetDataSize() -
1);
> +
> m_pFileObject->Read(m_ulReadBytesRequested);
> + }
> + else
> + {
> + // This is one of
those
> strange 1-byte FLV packets,
> + // so we don't really
have
> any data to provide for
> + // this packet, so go
on to
> read the next FLV packet.
> + //
> + // Set the state
> + m_ulState =
kStateGPReadDonePending;
> + // Save the number of
read
> bytes requested
> + m_ulReadBytesRequested
=
> HX_FLV_TAG_HEADER_SIZE + 1;
> + // Read an FLV tag
header.
> We read one more byte
> + // since for audio and
video
> packets, the first byte
> + // after the tag
header is
> packet info. For meta packets,
> + // there is no such
byte,
> but we are skipping meta packets
> + // since we read them
> earlier in the GetFileHeader() call.
> +
> m_pFileObject->Read(m_ulReadBytesRequested);
> + }
> }
> }
> }
>
>
> =====================================
> Eric Hyche, Technical Lead
> RealNetworks, Inc.
> ehychereal.com
>
>
> _______________________________________________
> Datatype-dev mailing list
> Datatype-devhelixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/da
tatype-dev
_______________________________________________
Datatype-dev mailing list
Datatype-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/da
tatype-dev
|
|
| CN-Client: fix FLV playback for odd
1-byte FLVpackets |
United States |
2007-08-28 19:04:47 |
Thanks for the review, Henry. This is now checked
into HEAD, 150Cay, 203Cay, 204Cay, and 310Atlas.
=============================================
Eric Hyche (ehychereal.com)
Technical Lead
RealNetworks, Inc.
> -----Original Message-----
> From: Henry Ping [mailto:pingreal.com]
> Sent: Tuesday, August 28, 2007 5:11 PM
> To: ehychereal.com; datatype-devlists.helixcommunity.org
> Subject: RE: [datatype-dev] CR-Client: fix FLV playback
for
> odd 1-byte FLVpackets
>
> Looks good.
>
> Henry
>
> > -----Original Message-----
> > From: datatype-dev-bounceshelixcommunity.org
> > [mailto:datatype-dev-bounceshelixcommunity.org] On
Behalf Of
> > Eric Hyche
> > Sent: Tuesday, August 28, 2007 12:34 PM Ping
> > To: datatype-devlists.helixcommunity.org
> > Subject: [datatype-dev] CR-Client: fix FLV
playback for odd
> > 1-byte FLVpackets
> >
> >
> > [I'm going to go ahead and check this in on the
203Cay branch
> > so Rhapsody QA can regress the associated bug.
I'll wait on
> > the rest of the branches until I hear back...]
> >
> > Description
> > ---------------------------------------
> > Previously I have never run across any FLV files
that had FLV
> > packets with packet data sizes less than 2 bytes.
> > That's because the 1st byte of data is always a
header, so
> > only having 1 byte of FLV packet data would
essentially mean
> > you had NO data - a NULL packet.
> >
> > However, during Rhapsody testing the Rhapsody QA
team ran
> > across some FLV files like this. The current FLV
fileformat
> > failed to read these files. This fix corrects
this,
> > essentially skipping those FLV packets which only
have 1 data byte.
> >
> > Files Modified
> > ---------------------------------------
> > datatype/flash/flv/fileformat/flv_file_format.cpp
> >
> > Branches
> > ---------------------------------------
> > HEAD, 150Cay, 203Cay, 204Cay, 310Atlas
> >
> > Index: flv_file_format.cpp
> >
============================================================
=======
> > RCS file:
>
/cvsroot/datatype/flash/flv/fileformat/flv_file_format.cpp,v
> > retrieving revision 1.6.2.1.2.1.6.3
> > diff -u -w -r1.6.2.1.2.1.6.3 flv_file_format.cpp
> > --- flv_file_format.cpp 22 Aug 2007 18:08:07 -0000
> > 1.6.2.1.2.1.6.3
> > +++ flv_file_format.cpp 28 Aug 2007 19:27:55
-0000
> > -1179,8 +1179,35
> > m_ulState =
kStateGPTagReadDonePending;
> > // Save the number of
read bytes
> > requested
> >
m_ulReadBytesRequested =
> > m_cTagHeader.GetDataSize() - 1;
> > + // In some rare FLV
files, the
> > data size of an FLV
> > + // packet can be 1.
If we hit
> > one of these packets,
> > + // then we don't need
to read
> > any of the rest of the
> > + // packet body, but
rather go
> > straight on to reading
> > + // the next FLV
packet.
> > + //
> > + // Do we have more
bytes to read
> > for this FLV packet?
> > + if
(m_ulReadBytesRequested)
> > + {
> > // Read the rest of
the tag
> > -
> > m_pFileObject->Read(m_cTagHeader.GetDataSize()
- 1);
> > +
> > m_pFileObject->Read(m_ulReadBytesRequested);
> > + }
> > + else
> > + {
> > + // This is one of
those
> > strange 1-byte FLV packets,
> > + // so we don't
really have
> > any data to provide for
> > + // this packet,
so go on to
> > read the next FLV packet.
> > + //
> > + // Set the state
> > + m_ulState =
> kStateGPReadDonePending;
> > + // Save the
number of read
> > bytes requested
> > +
m_ulReadBytesRequested =
> > HX_FLV_TAG_HEADER_SIZE + 1;
> > + // Read an FLV
tag header.
> > We read one more byte
> > + // since for
audio and video
> > packets, the first byte
> > + // after the tag
header is
> > packet info. For meta packets,
> > + // there is no
such byte,
> > but we are skipping meta packets
> > + // since we read
them
> > earlier in the GetFileHeader() call.
> > +
> > m_pFileObject->Read(m_ulReadBytesRequested);
> > + }
> > }
> > }
> > }
> >
> >
> > =====================================
> > Eric Hyche, Technical Lead
> > RealNetworks, Inc.
> > ehychereal.com
> >
> >
> > _______________________________________________
> > Datatype-dev mailing list
> > Datatype-devhelixcommunity.org
> > http://lists.helixcommunity.org/mailman/listinfo/da
tatype-dev
>
_______________________________________________
Datatype-dev mailing list
Datatype-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/da
tatype-dev
|
|
[1-3]
|
|