[mythtv] Anyone working on direct MPEG2 encoding?

[Geoffrey Hausheer]

On Fri, 2 Jan 2004 00:28:56 +0100, "Kenneth Aafløy said:
> This would actually be trivial, as long as you familiarize yourself with
> the api. Once you get the hang of it all it goes like a dream. There is
> a couple of api examples in the ffmpeg cvs reposotory (donno if they'r
> in mythtv cvs), and there is also the core ff* programs to use as a
> reference point.
The 'non-trivial' part is actually geting it to work with myth, not doing
the encoding.  You will need to write yet another 'RecorderBase'
implementation.  As to how hard that is....I guess we'll see when someone
does it.
> 
> > However, I can't imagine this working in real time.
> > I think using mpeg2enc would be a bad idea.  libav* is
> > already well integrated in mythtv, and the ffmpeg guys
> > have been doing a lot of work on mpeg2 lately.
> 
> Using external encoders for encoding live content is not a very good
> idea, since this involves moving a lot of data around. What external
> transcoders(dec/encoders) is ideal for is in combination with the
> mythtranscode stuff, as these could use as much resources as they want.
> 
umm ffmpeg==libavcodec, so I'm not sure what you're saying unless you are
just agreeing with me.

> On the subject of frame exact cuts it might help if the framework for
> (re)encoding was flexible enough. This assuming (if considering ending)
> that you would set up a decoder, and decode the frames from the last
> keyframe to the frame you are interrested in, and them setup a encoder
> (with the same format as the existing stream), and encode the last
> frame(s) output by the decoder, and append those to the mpeg stream
> (doing this in slight reverse for the beginning).
> 
well, I do exact cuts in mpeg4 by adding some compliaction to the nuv
format.  I'm not sure it was the right way to do things now, but it is a
choice I made 6 months ago.  For mpeg2 it is harder because the format is
much more constrained (some decoders don't like varying the frames/gop,
so to get compliant streams, it will be tricky even assuming reencoding).
 There are tricks that can be played, but I haven't found a good way to
make it frame exact without at least inserting some dummy frames.


> > Anyhow, I'm not aware of anyone working on it, though last
> > time I proposed to attempt it (knowing a lot less about
> > MPEG2 than I do today), there wasn't all that much interest.
> 
> When just considering mpeg2 encoding from a v4l(2) capture card, the
> benefit is slim. But if, as previously noted, the api layer (or whatever
> you call it) could be made flexible enough to do more than that...
I was initially talking about a software implementation (back befroe the
ivtv drivers were usable).  RecorderBase would need quite a lot of work
to make it flexible enough for that though.  It really isn't written with
libavformat style streams in mind.  But since i haven't tried, it may be
easier than I think.

> This is offcourse dependent upon the hardware this is used on, and the
> future development of mpeg2 encoding in ffmpeg. Also the bitrate and
> quality parameters should have a hand in the equation. You seem to
> elaborate on the fact that 1-pass encoding is weak, but I must object to
> this opinion a bit.
It is one of the methods that can be used with any other encdoing method
to make the encoding better (choosing where to spend your bits better
will always help).  However until someone comes up with an ingenious
algorithm for compressing the data, or hardware gets much more powerful,
I don't think real-time MPEG2 encoding at, say, DVD resolution, is
realistic.

All of these arguments apply to improving MPEG4 as well.  We currently do
fine with 1-pass encoding.  However, I've heard that there are new
switches in ffmpeg (and thus libavcodec) that can help a lot with little
processor impact.

Anyhow, I'll shut up now, as I doubt I have anything else that would help
anyone who attempts to do the implementation.

.Geoff