[mythtv] Lossless MPEG2 editing!

[manu]

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