> > Hiya, > > > > Been a while since I've written here. > > > > I've got an idea brewing for a new project that would involve reading > > raw data packets from various segments of similarly encoded video files > > (h264) and re-muxing them into one file. > > > > Essentially, it would be a raw packet AV editor. I'd like to have it so > > that I can queue up multiple video clips, one after the other and each > > with an in time point and out time point. From there I'd read the raw > > packets from the in time point until the out time point of the video > > files and splice them into one file. > > > > Before I get into it, however, I was wondering if I could solicit some > > advice here about the possibilities and limitations of that. Would > > there be problems in keeping the AV in sync? I assume that if I wanted > > exact timing, I would have to decode certain packets at the beginning or > > end of > > a time point that weren't exactly aligned with the give time point and > > re-encode them. Would it then be possible to get the exact encoding > > parameters from the AV streams so that I could re-encode portions using > > the same parameters? Would it even be thinkable to mix the raw packets > > from the camera-created video file with ones I create myself? > > Hmm interesting idea. Compressed packet remuxing is a very important feature > for me although I use it only for complete files (e.g. for re-tagging music > files or putting Divx AVIs with separate subtitles into one .mkv file). > > Some things you might want to consider: > > - Transcoded video files can only be cut at keyframe boundaries. And even then > there can be open-GOPS, which means that after a keyframe there come some > B-frames from the previous GOP. Limiting the application to I-frame only > formats would simplify things a lot. > > - Splicing compressed audio packets is also not always possible because some > compression formats use overlapped transforms. This means that the first > samples > of every packet depend on the last samples of the previous packet. > I outlined soem details about that here: > > http://hirntier.blogspot.de/2010/08/getting-serious-with-sample-accuracy.html > > - Setting up an encoder with exactly the same parameters as a compressed > stream > is also a major challenge. It will surely suceed for simple formats like > JPEG or DV. For things like H.264 I would probably not even try it :) > > Seeking in a stream, from which you read compressed packets, is not supported > yet in gmerlin-avdecoder. I can enable it, but then the first PTS after a seek > might be much smaller than the target PTS because my demuxers seek to the > point, > from which the stream can be decoded again.
Hi Burkhard, Thanks for taking the time to reply. Given what you say about the complexity involved, and the impossibility of getting the encoding settings from the bit stream, I don't think I'll be pursuing it much further. -august. ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ Gmerlin-general mailing list Gmerlin-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gmerlin-general
