[FFmpeg-devel] qt-faststart update

[Frank Barchard]

On Wed, Jun 24, 2009 at 11:58 PM, Reimar D?ffinger <Reimar.Doeffinger at gmx.de
> wrote:

> On Wed, Jun 24, 2009 at 07:29:16PM -0300, Ramiro Polla wrote:
> > On Wed, Jun 24, 2009 at 6:22 PM, Reimar D?ffinger
> > <Reimar.Doeffinger at gmx.de>wrote:
> >
> > > On Wed, Jun 24, 2009 at 10:07:47PM +0200, Karl Blomster wrote:
> > > > Frank Barchard wrote:
> > > >> Thank!  The types should be possible to deal with.  Any suggestions
> for
> > > a
> > > >> portable 64 bit fseek?
> > > >
> > > > I think
> > > >
> > > > #ifdef _WIN32
> > > > #    ifdef __MINGW32__
> > > > #        define fseeko fseeko64
> > > > #      define ftello ftello64
> > > > #    else
> > > > #        define fseeko _fseeki64
> > > > #        define ftello _ftelli64
> > > > #    endif
> > > > #endif
> > > >
> > > > is the closest you're going to get.
> > >
> > > See MinGW patches to add this feature. There is already a bug report
> with
> > > an unfinished patch. That is the only proper place.
> >
> > I think that patch doesn't fit here... He wants VC support, not MinGW32.
>
> Well... I think the basic idea would still be very similar. There is
> already a inttypes.h reimplementation for VC, something similar could
> probably be done for stdio.h, too, with some hacks for 64 bit file
> access support.


Upgrading to VS2008 didn't help with types or fseeko.  I'll look at VS2010.
 If the code wont come to the compiler, maybe the compiler will come to the
code :)

Removing VC support and using 1k blocks, I was concerned about loosing
performance.  (Muxing and running qt-faststart is more of a bottleneck than
I expected)
First I compare mp4box to ffmpeg for mux performance.  I run it on one
drive, vs two drives where the destination is a different folder
ffmpeg -y -r 23.976 -i sonyh2.m4a -i sonyh.264 -vcodec copy -acodec copy
sonyh2.m4v

Muxer Time (milliseconds) Time (minutes) ffmpeg 1 drive 1,326,533.07 22.11
ffmpeg 2 drives 1,295,611.71 21.59 mp4box 1 drive 10,386,286.79 173.10
mp4box 2 drives 13,068,641.76 217.81
qt-faststart.vc32k 1 drive 1,384,525.08 23.08 qt-faststart.vc32k 2 drive
242,990.97 4.05 qt-faststart.gcc1k 1 drive 1,375,145.10 22.92
qt-faststart.gcc1k 2 drive 225,813.66 3.76 Total test 29,317,694.07 488.63

So the GCC version runs great, but is just as slow as ffmpeg mux. It would
be nice not to need this step.
mp4box puts the moov header at the start, but unless we get the mov.c patch
to avoid seeking to the end of file, its not a win.

Is the 'free' atom patch good? If so, I'll proceed with the bug fix patch.

Here is the diff, but not base64 encoded this time




>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: qt-faststart.diff
Type: application/octet-stream
Size: 3326 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090626/1945a4e5/attachment.obj>