[FFmpeg-devel] [PATCH 2/2] g2meet: factor out chunk seeking
michaelni at gmx.at
Sun Feb 9 00:06:07 CET 2014
On Sat, Feb 08, 2014 at 11:24:42PM +0100, Michael Niedermayer wrote:
> On Sat, Feb 08, 2014 at 11:03:23PM +0100, Maxim Polijakowski wrote:
> > Am 08.02.2014 22:45, schrieb Michael Niedermayer:
> > >On Sat, Feb 08, 2014 at 10:27:51PM +0100, Maxim Poliakovski wrote:
> > >>This version requires fewer code and is safer.
> > >>---
> > >> libavcodec/g2meet.c | 21 ++++++++-------------
> > >> 1 file changed, 8 insertions(+), 13 deletions(-)
> > >>
> > >>diff --git a/libavcodec/g2meet.c b/libavcodec/g2meet.c
> > >>index b982eab..c2fceda 100644
> > >>--- a/libavcodec/g2meet.c
> > >>+++ b/libavcodec/g2meet.c
> > >>@@ -646,7 +646,7 @@ static int g2m_decode_frame(AVCodecContext *avctx, void *data,
> > >> int magic;
> > >> int got_header = 0;
> > >> uint32_t chunk_size;
> > >>- int chunk_type;
> > >>+ int chunk_type, chunk_start;
> > >chunk_start should be 64bit as file positions could be 64bit in theory
> > >also chunk_start + chunk_size could overflow if they are both 32bit
> > Because we're working with frame data wrapped into a bytestream,
> > chunk_start and chunk_size indicate some position within a single
> > frame, which data size is very unlikely to be bigger than 2^32 bits.
> > There are no file operations performed at all. Perhaps the word
> > "seeking" was abit misleading here...
> true its ok as is but still a bit risky
> sizes in C generally should be size_t which can be 64bit
> AVPacket uses int instead and the bytestream api also uses int
> so theres no problem ATM
> if bytestream and AVPacket get upgraded to 64bit or size_t the there
> is a probem though, so it might still make sense to use 64bit for
> saftey ...
> anyway, if you prefer it as it is, ill apply it, its not wrong
if you or someone else wants to change the variables to something bigger
then int, thats welcome but theres lots of code across the
codebase that uses ints for this so this really shouldnt hold the
If size of AVPackets or bytestream gets changed, theres lots of code
that needs checking and updating
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel