[mythtv-users] Cutting commercials without expensive transcoding

papenfuss at juneau.me.vt.edu papenfuss at juneau.me.vt.edu
Sun Mar 14 09:56:47 EST 2004


> > - 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.


> > - 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

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.

> 
> > 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... 
:)

> 
> > 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.

> 
> > 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... :)

> 
> >
> > 	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.

-Cory

-- 
*************************************************************************
* The prime directive of Linux:  					*
* 	- learn what you don't know, 					*
* 	- teach what you do.						*
* 						(Just my 20 USm$)	*
*************************************************************************




More information about the mythtv-users mailing list