Date: 2/9/2008
| For a long time I've had a private stock app that manages encoding DVB mpeg2 to whatever compressed video format is in fashion. Which at the moment is H.264.
So anyway recently I started pushing HD through it and well it did not like that at all. Basically after much head scratching I worked out that avisynth, which serves up frames to x264 was "guessing" the length of the input mpeg2 file, or more correctly, one of the filters in it's direct show graph was doing the guess. Unfortunately, because Avisynth has to report an exact length of it's AVI at startup it means that the video stream is only ever as long as Avisynth's "guess". This is unacceptable, and there is only one route around this, and that is not to use direct show (i.e. DirectShowSource). So the option is using Mpeg2source filter plugin (oh no yet another dependency!). And that relies on an indexer to produce d2v indexes of the mpeg2 first. So now my graph looks like this:
This is a graphical editor for video processing blocks that I've been working on. Essentially the current system is a hardcoded version of this, but when I'm done, all the same functionality will be plug and play, probably with some scripting support as well.
This week I did finally get my mpeg parsing library up to snuff so that it can dump out all the meta data for a mpeg video stream (not PS/TS, just video at this stage) which is a good step forward. At the moment the mpeg2demux stage runs Pvastrumento which is the best error correcting demuxer available. However I'm about halfway to having a demuxer myself, and I suspect that I can create something that can compete with the error correcting capabilities of Pvastrumento and probably produce a d2v file in the process. So that would greatly simplify the whole diagram and get rid of that ungainly d2v indexing step.
Eventually I'll build up a library of components and graphs to handle the vast majority of media re-encoding needs and possibly release it as an application.
|
