[mythtv] Lossless MPEG2 editing!
manu
eallaud at yahoo.fr
Tue Jan 25 11:24:13 EST 2005
Le 21.01.2005 09:14:15, manu a écrit :
> Le 21.01.2005 05:08:35, Cory Papenfuss a écrit :
>>> Sorry to chime in... but I posted a bug report to point out that
>>> mythtranscode does not work for me with cutlists (it does a great
>>> job of transcoding RTJPEG->MPEG4 though). Is there another way to
>>> do that (almost as easy as transcoding directly from the frontend)?
>>> Thanks,
>>> Manu
>>
>> The quick and most accurate answer is probably "No." I'm not
>> completely sure what you're asking for. A program for hand-editing
>> out commercials is avidemux... works pretty well. It doesn't need
>> to reencode, but it can.
>>
>> Regarding lossless MPEG2 cutting, there are a number of issues:
>>
>> - Funky MPEG2 streams... between ivtv/DVB/HDTV/Dig Cable, there are
>> lots of different bits within a "standard mpeg2 stream." There can
>> be *lots* of other streams and formats of wrappers, packets,
>> substreams, etc all under the umbrella of an "MPEG2 capture"
>>
>> - GOP vs. non-GOP accurate edits. MPEG2 streams have I, P, and B
>> frames. Only the I frames can "stand alone." The other two rely on
>> previous/future combinations of other frames to generate a frame.
>> That means that cutting arbitrary frames is difficult to make a
>> lossless operation. Some re-encoding around the cutpoints is
>> usually necessary, even if cutting on GOP boudaries. Read the
>> GOPchop docs for more on this.
>>
>> - GOP length: Real-time encoders (e.g. ivtv-based cards) don't have
>> the benefit of noncausal filtering (read: they can't predict the
>> future), so they make compromises quality of the video for a given
>> bitrate. AFAIK, the hauppauge cards and ivtv driver combination
>> only produce one GOP sequence, which is about 15 frames long.
>> That's roughly 1/2 second.
>>
>> - Sync: Audio and video packets don't have to be very close to each
>> other. It's probably likely that a good MPEG2 stream cutter will
>> also have to be a rudimentary player to figure out which streams and
>> packets are really necessary to fully decode something. Since MPEG2
>> streams are both pseudo-realtime and packetized, they have
>> Presentation Time Stamps embedded to allow for prebuffering of
>> data. This can then be "presented" at the correct time. If you
>> take a chunk out of the middle, all PTSs past this point now need to
>> be tweaked.
>>
>> I'm sure I'm forgetting some things, but those are some that
>> I've run across. If it were easy, it'd be done by now.... :)
>>
>
> Thanks a lot for the explanation. I knew it was not straightforward,
> but I didn't know it was soooo bad ;-)
> Well my question was about cutting with/without reencoding in myth,
> because a while ago I used this feature (mythtranscode) and recently
> it was not working anymore. But someone told me it is back on its
> feet now, so I am happy. Obviously it seems that a good editing tool
> is not an easy thing to code.
> Thanks,
> Bye
> Manu
Well it works but the resulting stream seems to be a bit problematic
with respect to seeking. It just sits there stuck when I try to seek.
Any ideas?
Bye
Manu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20050125/73782e18/attachment.pgp
More information about the mythtv-dev
mailing list