Path: csiph.com!usenet.pasdenom.info!news.etla.org!news.stack.nl!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <b42ca928-ec8d-4388-adc6-df48b246e275@googlegroups.com>
References: <b42ca928-ec8d-4388-adc6-df48b246e275@googlegroups.com>
Date: Tue, 7 May 2013 22:00:10 +1000
Subject: Re: use python to split a video file into a set of parts
From: Chris Angelico <rosuav@gmail.com>
To: python-list@python.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1404.1367928012.3114.python-list@python.org>
Lines: 84
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:44883

On Tue, May 7, 2013 at 9:15 PM, iMath <redstone-cold@163.com> wrote:
> I use the following python code to split a FLV video file into a set of p=
arts ,when finished ,only the first part video can be played ,the other par=
ts are corrupted.I wonder why and Is there some correct ways to split video=
 files

Most complex files of this nature have headers. You're chunking it in
pure bytes, so chances are you're disrupting that. The only thing you
can reliably do with your chunks is recombine them into the original
file.

> import sys, os
> kilobytes =3D 1024
> megabytes =3D kilobytes * 1000
> chunksize =3D int(1.4 * megabytes)                   # default: roughly a=
 floppy

Hrm. Firstly, this is a very small chunksize for today's files. You
hard-fail any file more than about 13GB, and for anything over a gig,
you're looking at a thousand files or more. Secondly, why are you
working with 1024 at the first level and 1000 at the second? You're
still a smidge short of the 1440KB that was described as 1.44MB, and
you have the same error of unit. Stick to binary kay OR decimal kay,
don't mix and match!

> print(chunksize , type(chunksize ))

Since you passed chunksize through the int() constructor, you can be
fairly confident it'll be an int :)

> def split(fromfile, todir, chunksize=3Dchunksize):
>     if not os.path.exists(todir):                  # caller handles error=
s
>         os.mkdir(todir)                            # make dir, read/write=
 parts
>     else:
>         for fname in os.listdir(todir):            # delete any existing =
files
>             os.remove(os.path.join(todir, fname))

Tip: Use os.mkdirs() in case some of its parents need to be made. And
if you wrap it in try/catch rather than probing first, you eliminate a
race condition. (By the way, it's pretty dangerous to just delete
files from someone else's directory. I would recommend aborting with
an error if you absolutely must work with an empty directory.)

>     input =3D open(fromfile, 'rb')                   # use binary mode on=
 Windows

As a general rule I prefer to avoid shadowing builtins, but it's not
strictly a problem.

>         filename =3D os.path.join(todir, ('part{}.flv'.format(partnum)))
>     assert partnum <=3D 9999                         # join sort fails if=
 5 digits
>     return partnum

Why the assertion? Since this is all you do with the partnum, why does
it matter how long the number is? Without seeing the join sort I can't
know why that would fail; but there must surely be a solution to this.

>     fromfile =3D input('File to be split=EF=BC=9A ')           # input if=
 clicked

"clicked"? I'm guessing this is a translation problem, but I've no
idea what you mean by it.

What you have seems to be a reasonably viable (not that I tested it or
anything) file-level split. You should be able to re-join the parts
quite easily. But the subsequent parts are highly unlikely to play.
Even if you were working in a format that had no headers and could
resynchronize, chances are a 1.4MB file won't have enough to play
anything. Consider: A 1280x720 image contains 921,600 pixels;
uncompressed, this would take 2-4 bytes per pixel, depending on color
depth. To get a single playable frame, you would need an i-frame (ie
not a difference frame) to start and end within a single 1.4MB unit;
it would need to compress 50-75% just to fit, and that's assuming
optimal placement. With random placement, you would need to be getting
87% compression on your index frames, and then you'd still get just
one frame inside your chunk. That's not likely to be very playable.

But hey. You can stitch 'em back together again :)

ChrisA