Geoffrey Hausheer wrote:
>>
>>My first aim is to be able to get the transcoder to run on the files
>>without re-encoding the stream, but merely honouring the cutlist. After
>>that, I want to experiment with some other things. In turn, I think this
>>means I have to do some work to help correlate between the DVB capture
>>side, the recording profiles, and the transcoding profiles.
>
> First I'd recommend getting the transcoder to work with DVB with full
> reencode. I don't have a DVB card, but this should theoretically work
> today (if not, it is an issue with the decoder that needs fixing).
I can understand this would be a good way to start. At least that helps
to show that its integrated on the "input" side of the transcoding...
> As
> for honouring the cutlist and keeping the mpeg2 stream (like we already
> do for mpeg4), you need to be able to reencode key frames in mpeg2 format
> (because you need to mark a key frame after the 'cut'). I'm not aware of
> any legally free tools to do this, but someone had mentioned bbmpeg as an
> option (I've not looked into it).
Me neither. Most tools seem to be oriented toward cuts at the keyframe.
> This is easy enough. There are two 'types' of profiles. the first type
> used during normal encoding defines Default, Live TV, LowQ, and HighQ.
> These names are used regardless of the card type, and the correct
> preferences are chosen based on the card which is recording.
Straightforward.
> the second
> 'type' of profiles are used for Transcoding. currently only 'MPEG2' and
> 'RTjpeg/MPEG4' are defined. These are defined based on the stream type,
> and currently the only streams supported are MPEG2, RTJPEG, and MPEG4.
OK. So this means I could do one recording under the HiQ profile, and
another recording under the LoQ setting, both ending up as MPEG4 on disk
(nothing to do with DVB on this comment...). Then the transcoder runs,
either automatic or manual, would treat each of the streams identically?
At first glance, I'd expect the transcoder to treat the two profiled
recordings differently. It seems like it would be better to have the
transcoding configuration defined per stream *and* per type-1-profile.
ie Transcoding settings would have a set of values for HiQ MPEG4
recordings, and another set of values for LoQ MPEG4 recordings.
To do this, I guess, would require a parameter with each recording to
indicate the profile used to record it. And invoking manual transcoding
maybe ought to offer the ability to change the profile.
For example, I might make a HiQ recording, watch it in HiQ, then decide
to keep it, but have it transcoded to LoQ to free up disk space.
I
> suppose MJPEG should be in there too, but I don't have such a card, and
> am not sure how to handle it. DVB is not supported at all for trans
> coding, because, again, I don't have the hardware, but it should be
> peretty easy (from the transcoders point of view, it should look very
> much like the output of a PVR-250). So there probably needs to be some
> massaging there, but I don't think any new profiles are needed (or
> perhaps there DOES need to be a 'DVB' profile in the Trancoding group).
One thing I'm concerned about is the very different nature of the MPEG2
streams. The PVR-cards ought to give a perfect MPEG2-encoding of a (less
than perfect) analogue signal, while the DVB card is more likely to be a
less-than-perfect MPEG2 stream. The latter is more likely to suffer from
packet loss, header problems and sync mis-alignment.
Indeed I do suffer from these problems. And occasional dropouts in the
stream *can* cause lasting problems with the video decoder, whenever I
watch the recording.
There is room somewhere in the chain for some error-correction, packet
fixing, and sync code. I'm not sure if it can be done in the initial
capture, so the transcoder might be the place.
>>If I've got things understood correctly, then, when altering the setup
>>of recording profiles...
>>
>>Selecting a group of "Hardware DVB Encoders", I should get the 4
>>profiles. If I choose "Live TV", I should then be able to set the
>>parameters with which I wanted "Live TV" to be spooled into the disk
>>with (including capture card settings, and any software codec settings).
>>If I select one of the other 3, I should be able to set the parameters
>>for which recordings are made (same capture card settings and software
>>codec settings), then each individual recording may specify one of those
>>3 profiles.
>>
>>Selecting a group of "Transcoders", I should be able to see all the
>>possible file encoding types for recordings originally captured using
>>the profiles above, and for each one, specify new software codec
>>settings for the transcoder to turn the recording into.
>
>
> Not quite. As I said above...we can't map profiles to a transcoder (what
> if the profile has changed since the recording was made). So transcoding
> decisions can only be made based on format (not based on any other
> settings).
My original understanding was that the transcoder chose what to do
merely based on the format of the stream coming in, though perhaps I
didn't express that well :-). However, from what I said above, I think I
have convinced myself (if no-one else) that its worth being able to
specify transcoding based on the incoming profile.
>>I hope I've got those right... The rest is based on this...
>>
>>So, for capturing from DVB cards, we ought to be able to see/change some
>> setup data for the capture card, plus any additional software
>>transcoding we do between the capture card and the disk.
>>
>>These parameters might include, for example, aspect ratio, resolution,
>>but wouldn't include channel tuning parameters, or parameters to
>>determine whether to output the whole TS or individual PES.
>
> The transocder does not support changing aspect ratios or resolution, and
> I see no reason to support these (it requires a huge amount more
> work...which would be better suited to an external program, perhaps using
> the fifo interface).
Perhaps I should ask what the transcoder's purpose is then!
I always saw it as a tool to help invoke an encoder that couldn't (or
shouldn't) be run on a live recorder, perhaps because cuts need to be
made manually, or perhaps the CPU/system/disk requirements were too high
to be done live. And generally, that the output of transcoding was more
"archiveable" than the input.
If that's the case, then it doesn't really matter whether the transcoder
acts as the front-end for something trivial or for something that
requires a huge amount of work, or indeed merely acts as the front end
for an external program. Perhaps the transcoder should be just that - a
front end to a number of pluggable filters.
Over the long term, I have in mind some kind of grander replacement for
MythVideo - a kind of MythArchiver. The recorders capture something
appropriate for (relatively) immediate viewing & deletion. Transcoding
takes some of these, and re-encodes into something more appropriate for
keeping longer term, and archiving off-line. The archiver might put the
AV data off-line, but would keep recording information in the DB.
Indeed, the DB might help track recordings of series, or sports events
in addition to Movies.
The off-line storage of the video might involve extra hard-disks,
removeable hard-disks, tapes, CD or DVD. And might be held in a
data-oriented fashion (only replayable on a Myth system) or in a
standard format (VCD/SVCD/Video-DVD) replayable in the outside world.
>>As I see it at the moment, there aren't really *any* parameters to set
>>for capture from the hardware - we basically get the stream in whatever
>>MPEG-2 format the broadcaster chose to send it. And right now, there
>>aren't any parameters to set for any intermediate software transcoding
>>before the stream hits the disk either - though I can see the need for
>>some later, perhaps in transcoding from the PVA/PES format of the DVB
>>transmission through some error-correction and/or AV-sync code.
>
> This is all true. The DVB is a special case in that you have no control
> over what format you get the stream in. Are there any controllable
> parameters? if not, then we can just have the 'Default', Live TV', etc
> profiles have a single switch in them (whether or not this program should
> be auto-transcoded).
I'm pretty sure the hardware-side of the capture has no switches
involved (but, as I think Edward said, HD-TV might be slightly
different), so the best starting point is exactly what you say - only
have switches for auto-transcoding.
>>Similarly, when we want to setup the "Transcoders", we need to allow
>>transcoding from the DVB-MPEG2 into the existing RTjpeg and MPEG4
>>codecs, but we also need to allow a specification that the transcoding
>>should not re-encode either video or audio (or probably both), or to
>>force certain settings if the stream is not already of that format.
>
>
> Again as I said before, the first part should 'just work' today...or need
> a minimal amount of changes. Keeping MPEG2 streams needs more work. The
> easiest way to think about this is to assume you know nothing about the
> stream besides what is stored on the disk (i.e. make no decisions based
> on cards in the system, or any other encoding options). anything which
> is contained in the actual video file is fair game for making transcoding
> desicions.
Right. I've been looking at some other tools that do MPEG2 -> MPEG2
transcoding, and all these work on the same premise. The stream is all
you have...
>>Today, we have two profiles for the transcoder: "MPEG2" and
>>"RTjpeg/MPEG4", but they appear to only allow to transcode towards the
>>RTjpeg and MPEG4 codecs - I don't see how you can configure the MPEG2
>>transcode to *not* re-encode (but I've read in the lists that it does.
>>Is this true?)
>
> You can't (as above). MPEG4 is the only format that can be 'commercial
> clipped' without reencoding (until this is fixed).
Glad to see my understanding was right.
>>Of course in deciding whether re-encoding is required for DVB, we won't
>>be able to compare all the capture settings with some transcoding
>>settings, as we have just taken the stream as the broadcaster sent it.
>>Recordings will be at different resolutions (certainly), with different
>>audio settings (possibly). I think we really will need some settings
>>that state "don't change".
>
> This will need some thought. We could easily make transcoding decisions
> based on resolution/format parameters, but making this into an intuitive
> interface may be challenging.
Too right.
I have seen two tools whose main purpose is to error-correct DVB MPEG2
streams, re-synchronise the audio & video, and insert NAV headers for
DVD authoring.
One is for Windows, and has very few controls. One is for Linux (using
Java), and has *pages* of controls. The latter works (and can be mostly
pre-configured), but its a hell of a user experience.
http://www.offeryn.de/dv.htm#pvas
and
http://forum.lucike.de/viewtopic.php?t=54&sid=64c8d5f7d3f42c8706a0ad04338cec12
(Sorry - it's mostly in German. The download link is near the bottom).
> Since I now have a PVR250, and have no other myth work on my plate, I'll
> start on the first part now, and see if I can remove commercials without
> reencoding the MPEG2 files.
Thats excellent news.
> That should leave the way open to all the
> rest of the changes you will need. I think the hardest part will be
> coming up with a good interface to control which programs get transcoded
> and which don't, and I haven't any clue on that.
I agree that this is the hard part. I don't have much of a clue either!
Cheers,
Mike