[mythtv-users] Cutting commercials without expensive transcoding

James L. Paul james at mauibay.net
Sun Mar 14 14:09:16 EST 2004


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 14 March 2004 4:56 am, papenfuss at juneau.me.vt.edu wrote:
> > > - The hardware encoders don't have the benefit of a 2-pass encoding
> > > scheme (being a causal device and all... :) or high-quality denoising,
> > > so they don't necessarily make the right choices on I/P/B frames all
> > > the time.  It makes sense to me that I frames should be used on large
> > > scene changes... but that's not necessarily done with the raw captured
> > > streams and causes wasted bandwidth. For the best quality/bitrate
> > > ratio, post-processing (i.e. *re-encoding*) will be necessary.
> >
> > Re-encoding isn't going to restore quality that isn't there. Also,
> > considering that the quality of the cable TV signal feeding the PVRx50
> > card is much lower than DVD quality to begin with, we're not talking
> > about creating high-quality DVDs, I thought we were talking only about
> > burning some commercial-cut TV shows to a standard format on plastic. ;)
>
> 	That's quite true, but I'm talking about the best quality/bitrate
> possible.  For NTSC captures, anything over 480x480 is wasted resolution. 
> If you scale that to typical DVD movie MPEG2 bitrate of 3.5 Mbps, the
> 480x480 shouldn't require more than 2.3 Mbps to obtain the same results. 
> The PVR-[23]50's tend to look pretty blocky at such low bitrates.  If
> captured at higher bitrate and then cut back, it can look better than if
> captured at low bitrate to start with, since the encoder has the potential
> advantage of 2-pass encoding, etc.

I think you have some misconceptions about the relationship of resolution to 
bitrate in MPEG video. MPEG isn't simply compressing pixels, and reducing the 
number of pixels doesn't simply reduce the need for bitrate. Regardless, I 
understand what you are saying and while it's true that with tweaking you can 
get the best possible results by using a 2-pass encoder for the final 
version, I personally haven't found it necessary. By the way, what encoder 
and switches are you using to encode MPEG2 in 2-pass mode? ;)

> > > - The avidemux program still has some issues with processing streams.
> > > Using the DVD-PS output file type produces DVD-compatible streams that
> > > are much larger than ones manually mux'd with tcmplex.  Unfortunately,
> > > extracting (or processing) video and audio streams separately generally
> > > tends to cause sync problems.  Also, is a DVD-PS (with NAV packets)
> > > acceptable as an SVCD stream?
> >
> > I don't understand. Manually muxing has nothing to do with file sizes.
> > I've had audio sync issues when capturing to elemental (non-PS) separate
> > streams, but never a problem with the PS streams output by my PVR250's.
> > Demuxing and remuxing my PVR250 streams has never produced any audio sync
> > issues for me at all.
>
> 	It doesn't seem like it should, but it does.  There's much more in a
> DVD mpeg stream that audio and video... and lots of choices that can be
> made. I did the same thing two different ways... a 1 minute clip muxed with
> avidemux's DVD-PS, and the other 'tcmplex -m dvd'.  Here are the resulting
> file sizes:
> 21720   test.m2v
> 1428    test.mp2
> 23912   test_tcmplexdvdps.mpg
> 27540   test_avidemuxdvdps.mpg

Wow, I'm surprised. Then again, I've never muxed with avidemux, I only use the 
raw video/audio. I also rarely use tcmplex, and usually use mplex.

> So, there's 3% overhead for the tcmplex'd one, and 18% overhead for the
> avidemux'd one.  There's lots of padding inserted from avidemux.
>
> The tcmplex'd version shows this from tcscan and vstrip:
> ------------- presentation unit [0] ---------------
> stream id [0xbb]    121
> stream id [0xbe]    123
> stream id [0xbf]    242
> stream id [0xc0]    722
> stream id [0xe0]  11098
> 12306 packetized elementary stream(s) PES packets found
> presentation unit PU [0] contains 121 MPEG video sequence(s)
> Average Bitrate is 5000. Min Bitrate is 5000, max is 5000 (CBR)
>
> Summary:
> MPEG Packs = 11942
> System headers = 121
> Padding packets = 123, total bytes = 129436
> Private 2 packets = 242, total bytes = 241758
> MPEG1 Audio 0 packets = 722, total bytes = 1454500
> Video 0 packets = 11098, total bytes = 22202806
>
> and the avidemux'd one shows:
> ------------- presentation unit [0] ---------------
> stream id [0xbb]     61
> stream id [0xbe]   3621
> stream id [0xbf]    122
> stream id [0xc0]   1813
> stream id [0xe0]  11879
> 17496 packetized elementary stream(s) PES packets found
> presentation unit PU [0] contains 121 MPEG video sequence(s)
> Average Bitrate is 5000. Min Bitrate is 5000, max is 5000 (CBR)
>
> Summary:
> MPEG Packs = 13753
> System headers = 61
> Padding packets = 3621, total bytes = 4031738
> Private 2 packets = 122, total bytes = 121878
> MPEG1 Audio 0 packets = 1813, total bytes = 1451520
> Video 0 packets = 11879, total bytes = 22211032
>
> > I assume that any DVD-PS stream is an incorrect format for SVCD, since
> > the SVCD stream specs are not DVD-compliant. So this answer would be no.
> > I don't see how it's relevant though, since the PVR250 doesn't output PS
> > streams with DVD NAV packets if I understand correctly. I believe it's
> > necessary to remux the PS stream to insert the NAV placeholders. And
> > again, no, this should not create any audio sync issues.
>
> 	Although I don't know for sure, I suspect that if there is extra
> information (like 0xbf DVD nav streams) that SVCD doesn't know about, it'll
> ignore them... so long as the video/audio streams are the right size/rate. 
> The PVR250s don't output NAV packets, but I don't think they're necessary
> for DVD players to play them... just if you want to do fancy things like
> seamless jumping, etc.

Why would you mux with DVD NAV at all for a SVCD target? They are only 
placeholders that will be filled in during the DVD authoring process, no? 
Without something like dvdauthor to generate the VOBU information and then 
stuff relevant information into those placeholders, they are useless. I 
didn't know vcdimager would even use a stream that has them. (Never tried.)

> > > There are a few different fundamental goals I can see would be useful
> > > for arching mythtv folks:
> > >
> > > 1. Simple, fast "VCR" functionality... quick and simple recording onto
> > > DVD from a PVR-[23]50 set to record in a DVD compatible format.  This
> > > would preferrably have commercial-cutting ability, but that's all.
> > > Advantages: Quick, easy (especially if no commerical cutting),
> > > CPU-efficient. Disadvantages: Not the most efficient use of space,
> > > can't specify
> > > "master-quality" recordings and then "archival-quality" DVD or SVCD
> > > since it's recorded/encoded in the final format.
> >
> > This is basically my own goal. I do it manually now. I don't feel the
> > disadvantage as strongly as you imply it to be, since if I really want to
> > shrink the size requirements I simply requantize the video instead of
> > re-encoding.
>
> 	I'm a bit of a perfectionist nut, so if I'm going to fry up something,
> I want to fill up the disk (with either quality or quantity).  I lament the
> lack of 2/3 D1 resolution (480x480) on the dvd standard, as 352x480 isn't
> broadcast quality and 704x480 is overkill.  The SVCD is right in
> resolution, but short on space without high-quality encoding.  In short,
> I'm just a nut...
> :)

I'm surprised you don't capture in 704x480 then. :) It may be overkill for the 
signal source, but I've had several perfectionists argue to me that it looks 
better. My position is that for cable-TV captures, 704x480 looks identical to 
352x480 when viewed via an NTSC output device. Resolution has nothing to do 
with image quality, as long as it's higher than the signal source. Bitrate is 
everything for MPEG2.

> > > 2. Efficient/convenient, "Archive" functionality... Recording at
> > > high-quality ("Master copy").  Commercial cutting and transcoding in
> > > post-processing.  This allows for the best quality/bitrate ratio and
> > > makes archiving to less expensive media (e.g. SVCD) or more pack more
> > > episodes onto DVD's.  Especially important for the SVCD/DVD decision,
> > > as the resolutions aren't compatible (480x480 for SVCD, 352x480 for
> > > DVD, and 704x480 which is gross overkill for cable-quality captures).
> >
> > Again, I've had good results with tcrequant instead of transcoding or
> > re-encoding the whole stream. Some of the archive DVDs I've done of
> > animated cartoons (think "Family Guy") requant very well and I've been
> > able to fit 6 hours or so on a single DVD with good quality.
>
> 	I've played with tcrequant, and I've been impressed.  My foray into
> using avidemux is an attempt at streamlining the process (including
> cuts)... preferrably without having to strip/crunch/remux.  The quality I
> got from an 1.2 factor tcrequant is noticably less than that from a
> reencode via avidemux, though.  Thus the multiple "modes" I described in
> the original email.... different targets require different compromises.

Very true. My results with tcrequant are very dependant on the source 
material. It's a very hard thing to automate.

> > > 3. Space efficient, "Computer archive" functionality.  Similar to #2,
> > > but with the ultimate goal of MPEG4 archiving on computer media.  Once
> > > the requirement of set-top box compatibility is removed, anything
> > > mplayer can play is valid.
> >
> > Agreed. Many issues drop away if you aren't targetting playability in
> > common set-top DVD players. :)
>
> 	Of course should set-top boxes play MPEG4's sometime in the future,
> life is good... :)

Yah. A couple do, but I think it's just playing files on an ISO disk ala the 
MP3-playing boxes. I'm not aware of any format that allows for MPEG4 on a DVD 
structure, official or otherwise. Yet. Unfortunately, I read something lately 
about Microsoft getting one of their proprietary codecs into the next 
standard.

> > > 	Did I miss anything?  :)
> >
> > Only things that come to mind right now are:
> >
> > 4. Instead of burning 1 show per disk, an interface for collecting
> > media-ready titles that can be accumulated and selected for burning
> > multiple captures to a single disk.
>
> 	Agreed.  I haven't even used nuvexport since the myth box is quite a
> PITA to access from the command-line or anything other than the
> "production" remote interface (no monitor/keyboard/network).
>
> > 5. The obvious menu-generation features that would be welcomed by users
> > of the preceeding #4. ;)
>
> 	Patience... :)  I got a DVD burner over a year ago and was quite
> dissappointed at the lack of linux DVD software.  It has gotten much better
> recently, and I think will eventually be quite good.  It's a lot to ask of
> mythtv to put a nice GUI on a nonexistent (or barely existent) backend
> toolset.

I knew things were raw when I got my burner almost 2 years ago. Things are 
_way_ better, but not there yet. At least I've been able to make my own 
custom menus and limited special features with dvdauthor, though with much 
time and effort.

> -Cory
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFAVK3fT8BYaKRUpkQRAtamAJ0U6Y7Af6HGOjmyJxo3DJHg8pmqggCgnyvc
zVbW5Xmtvo1KTY3RT0C6cAA=
=UHTS
-----END PGP SIGNATURE-----


More information about the mythtv-users mailing list