Let me see if I can sort of prioritize things, or
at least give a partial ordering of priorities.
In a perfect world, I would extract every single
frame/field/picture into a separate file along
with a duration that frame should be shown, and
similarly, the audio could be split up so there
are Ki (K is some whole number) independent audio
samples which go with picture i.
Then I could totally shuffle around all the
individual frames/pictures, put them back together
in a different permutation, and put it back into
a new MPEG-PS which has the same duration as the
original, and has all the same frames (with both
the video and the sound which was playing during
that frame), but in a different order. since no
information has been lost, I could later unshuffle
everything and get back the original MPEG-PS.
This is not my end goal, but if I had a choice
between either having this capability but having to
re-encode everything, or only having a granularity
of several seconds between cuts, I would prefer the
former. Maybe a way to put it succinctly is that I
/need/ the ability to cut/splice at a frame/picture
level, but I /want/ to avoid (lossily) re-encoding.
Presuming I can lossily split any segment into single
frames keeping exact timing information, and lossily
put it back together again, I will ballpark estimate
that if the stream was split into segments of 15
seconds each, the probability I would want to cut a
given segment is 10%, for 1 minute each, 25%, and for
4 minutes each, 50%. I am just trying to give a rough
idea of how much compromise there would need to be,
presuming if I am going to make a cut, I will have to
lossily convert that whole segment into single frames.
So if the average length of each segment was going to
be 5 minutes, I might was well just split the whole
file into individual frames, because I am going to
have to do that for most of the frames anyway.
A couple mitigating factors are that I am not worried
much about time and space issues. If I need 50GiB to
unpack a 1GiB VOB, that would be ok, and 0.5 seconds
per frame to decode/encode would be ok. Also, as far
as the audio, it is ok of the sample duration for the
audio and the frame duration for the video are coprime.
I do not mind fudging the audio.
Another thing is I do not /anywhere/ have any
sort of hard constraint of /no/ loss of video
information. In other words I am not going to, for
example, try to find the correlation between two
video streams by comparing individual frames, so if
as a practical matter there is enough information
in a segment to re-encode it in an "in effect,
visually lossless" way, that would be ok. I think
there is an option with mplayer (mencoder) to split
a stream into one PNG file per (what it thinks is
a) frame/field/picture, and (presumably) to create
a new stream from that. I am hoping to find a
significantly better approach than that.
I am not sure if I want to "[re-encode] frames
around the edges while still producing a conforming
MPEG-2 program stream with the VBV and all that". I
do want to be able to split a VOB into segments with
minimal loss of information ("minimal" meaning "as
little as I can feasibly achieve"), re-encode some
of the segments, and put it back together into a
valid MPEG-PS stream (eg that a typical consumer DVD
player can successfully play).
If there was already a simple command-line tool, or if
I got to wave my magic wand to create one, it would
be nice if I could tell it to start by splitting a
VOB into segments "visually losslessly", and then
to be able to take a particular segment, and tell
it to split that segment further, such that all the
segments have at least N quality, where "N" is similar
to saving a raster image as JPEG, and if the "quality"
is set to "1", there is a file for every frame.
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Libmpeg2-devel mailing list
Libmpeg2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmpeg2-devel
