HDTVtoMPEG2 latest version - Page 22 - AVS Forum
Forum Jump: 
Reply
 
Thread Tools
post #631 of 2239 Old 02-19-2005, 08:18 PM
AVS Special Member
 
nabsltd's Avatar
 
Join Date: Jul 2001
Location: Germantown, MD, USA
Posts: 1,284
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 14
Quote:


Originally posted by Xesdeeni
Here's the source for 1.10. I also have 1.08, if anyone cares.

ZIP files don't seem to work right as attachments in the forums, at least not with IE and XP SP2.
nabsltd is offline  
Sponsored Links
Advertisement
 
post #632 of 2239 Old 02-20-2005, 08:42 PM
Member
 
GrantR's Avatar
 
Join Date: Jan 2002
Location: Wellesley, MA
Posts: 187
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:


Originally posted by stjr
What ever happened to "GrantR" and the original H2 versions 1.09 beta and 1.10? I still use the 1.09 beta for my TS file splitting.

Hah, good timing, stjr. The first time I log on in half a year and there's someone asking about me. What happened? I got a bit sick of spending all my spare time coding when I spend all my time at work coding too, and decided to spend my time on other things.

I just finished up reading through 6 months of this thread, you guys should all be thankful for Cris taking such an active interest in continuing development!

BTW, I just earlier today removed my links and files off my website, as they're well out of date now, so that link Cris just posted won't work any more.

Re: speed issues

nabsltd, I wasn't happy with the original file copying speed when I began development on H2, and spent some time beating it over the head with a large multithreaded many-MB-chunk copying stick. You'd be hard pressed to get much more speed out of it. The limits (at least when I last looked at the source code) were pretty much in the OS's ability to do multithreaded file access - which Windows is usually fairly good at, so on a dual drive copy that limit should be close to the write speed of the destination drive. On my three different PCs I've edited on that has always held true. Newer versions may be doing more processing of the data as it is copied, however.

Re: commercial scanning

I can't quite remember where the current scan technique is at. I think I got sidetracked off to other things in the middle of developing it, then one day accidentally left the scan button active for a release If I remember correctly, it just scans through the file linearly. That was the simple case, for developing the 4x3 detection algorithms. Unfortunately it is slow, I can edit out the commercials by hand faster than that method can scan a whole file I wanted to implement a skip search algorithm, looking through the file in 30s or 60s intervals and then narrowing in on the transition points from there, which should have made it find commercials in under a minute. The 4x3 detection is nowhere near as simple as you might first think - almost no network around here actually has clean black borders! Fox for instance had borders that are almost black. Sometimes the borders are grey or have filler pictures in them. Sometimes there are network logos in there that spin and animate which ruins detection for static edges. Sometimes the borders actually vary in intensity a little bit while the 4x3 content is playing. Then there's all the parts of a show that end up getting tagged as commercial too. Soon more and more 16x9 commercials will show up and render this whole 4x3 detection method obsolete anyway.

I'm looking forward to seeing Cris's new audio cut fixes Chopping the ac3 packets off in random places at the cut points is really not the correct way to do it, but I never did get around to reading up on the audio stream format to try to figure that part out.

ok, so after a few random comments and answers, let's see if I disappear again for another 6 months.
GrantR is offline  
post #633 of 2239 Old 02-20-2005, 08:58 PM
AVS Addicted Member
 
TPeterson's Avatar
 
Join Date: May 2002
Location: San Carlos, CA
Posts: 11,846
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 3 Post(s)
Liked: 16
Grant--

Thanks for stopping by to chat! Yes, indeed, we are deeelighted that Cris has such a passion for H2 tweeking!

--Terry
TPeterson is offline  
post #634 of 2239 Old 02-20-2005, 11:01 PM - Thread Starter
AVS Special Member
 
balazer's Avatar
 
Join Date: Feb 2001
Location: Sunnyvale, CA
Posts: 3,317
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Commercial scan works perfectly for me on UPN.
balazer is offline  
post #635 of 2239 Old 02-20-2005, 11:31 PM
AVS Addicted Member
 
TPeterson's Avatar
 
Join Date: May 2002
Location: San Carlos, CA
Posts: 11,846
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 3 Post(s)
Liked: 16
I just confirmed lonndoggie's report here that previous H2 versions (at least version 1.09) do not crash upon attempting to open QAM-sourced TS files, as version 1.11 beta does. Perhaps this will be a useful clue, Cris, in figuring out what's going on with these files.

Version 1.09 actually displays the I frames if you manually enter the correct PIDs. Version 1.10, OTOH, doesn't crash on open but also resets the PIDs to 11 and 14 when you try to advance through the file, so I-frames aren't displayed. Version 1.10.5.1 already has the crash-on-open bug.
TPeterson is offline  
post #636 of 2239 Old 02-21-2005, 12:02 AM
AVS Special Member
 
nabsltd's Avatar
 
Join Date: Jul 2001
Location: Germantown, MD, USA
Posts: 1,284
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 14
Quote:


Originally posted by GrantR
nabsltd, I wasn't happy with the original file copying speed when I began development on H2, and spent some time beating it over the head with a large multithreaded many-MB-chunk copying stick. You'd be hard pressed to get much more speed out of it.

Well, when you did that, I noticed a huge jump in speed. But, lately, the speed hasn't kept up with my increase of hardware power (both CPU and disk speed).

Quote:


least when I last looked at the source code) were pretty much in the OS's ability to do multithreaded file access - which Windows is usually fairly good at, so on a dual drive copy that limit should be close to the write speed of the destination drive.

I'd love for that to be true for me, but sometimes I get 30MBps (still way below the 50-55MBps that the drive can write at) and sometimes 12MBps. I can't narrow it down to "source files from channel 7" or anything like that.

Quote:


Re: commercial scanning

NBC uses line 1080 for codes (similar to CC) that mark the change from "show" to "non-show". It should be easy to look for. Now, if we could get all the other networks to do something similar.
nabsltd is offline  
post #637 of 2239 Old 02-21-2005, 01:11 AM
Member
 
Gendal's Avatar
 
Join Date: Jan 2004
Posts: 45
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
MythTV has some pretty nice commercial scanning code, not sure how it compares to H2 at all or how useful it would be to peruse. Check out the cvs for the latest.
Gendal is offline  
post #638 of 2239 Old 02-21-2005, 09:22 AM
AVS Special Member
 
Cris Moore's Avatar
 
Join Date: Oct 1999
Location: Oregon
Posts: 1,157
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
TPeterson,

The instant crash in H2 Beta when using QAM files is do to the number of PMT's in the transport stream. I only allowed 10 PMT per transport stream. This was sufficient for OTA recordings. One of the sample QAM test files I got has 15 PMT's. Of the 15 sub-channels, only 3 are clear. What I plan on trying to do(if I can) is only list the clear channels in H2 for QAM channels.

There is also another issue with the PMT's, unique to the QAM channels, that are causing problems too that I will need to deal with.

Cris

Cris Moore is online now  
post #639 of 2239 Old 02-21-2005, 09:30 AM
AVS Addicted Member
 
TPeterson's Avatar
 
Join Date: May 2002
Location: San Carlos, CA
Posts: 11,846
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 3 Post(s)
Liked: 16
Cris--

I'm glad that the problem source has tumbled out.

Hmm...TSReader has the option either to show a "scrambled" window or not for encrypted subchannels. I can't think of a good reason to keep them but, in case there is one down the road, it might be better to follow TSR's example on this.

--Terry
TPeterson is offline  
post #640 of 2239 Old 02-26-2005, 01:24 PM
AVS Special Member
 
Xesdeeni's Avatar
 
Join Date: Mar 2003
Posts: 1,552
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
OK, this is silly. Technically this isn't HDTVtoMPEG2's problem, but the technical details seem to be discussed more here, so I'll see if this info helps:

I have the Fusion and the MyHD. Until last weekend, I had FF/RW problems recording on the Fusion and playing back with the MyHD with only one channel, FOX. Due to a problem with the Fusion (losing recordings), I was asked by DVICO to upgrade to their latest beta. And due to a problem with the MyHD (random system lockups), I was asked to upgrade to their latest version. I did both last Satruday. Since then I've recorded on FOX (no multicast), NBC (multicast), CBS (no multicast), UPN (multicast), and WB (multicast a spanish audio stream). Now I have FF/RW problems with FOX, NBC, and WB.

I'm not sure which program is the problem. I'll probably have to back one out and see.

But I don't think the NULL packes are the issue! I use multi-file recording. I had one recording that FF/RW fine until the last segment. Nothing changes between the segments regarding NULL packets.

What type of comparison would cut to the chase on this? If I took say a CBS stream that works (but Fusion already strips extras), and process it through HDTVtoMPEG2, and it didn't work, would that tell you anything? Then we could compare the streams and see what was missing, right?

Xesdeeni
Xesdeeni is offline  
post #641 of 2239 Old 02-26-2005, 01:48 PM
AVS Addicted Member
 
TPeterson's Avatar
 
Join Date: May 2002
Location: San Carlos, CA
Posts: 11,846
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 3 Post(s)
Liked: 16
Xesdeeni--

I don't know the answer but it is already well known that H2 processing of TS to strip nulls "breaks" their FF/RW in MyHD.
TPeterson is offline  
post #642 of 2239 Old 02-26-2005, 01:52 PM
AVS Special Member
 
Cris Moore's Avatar
 
Join Date: Oct 1999
Location: Oregon
Posts: 1,157
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
I remember Ron giving this as the reason why this happens:
Quote:
Whether null-stripped Transport Streams play well on MyHD is a function of how much PCR jitter there is. The worst case will be streams that are not using all of the 19.39 Mbps and the video is VBR (like FOX network). The best streams will be when the combined video and audio is close to 19.39 Mbps (in other words, not many null packets were stripped). However, there will be streams were the PCR's just happen to line up even though plenty of null packets have been stripped. These streams will typically be near CBR video and the stations Transport Stream muxer is using a well controlled "leak rate" such that video packets (which in ATSC, are always where the PCR is carried) are nicely spaced among the null packets(causing low PCR jitter).


Cris Moore is online now  
post #643 of 2239 Old 02-27-2005, 01:54 PM
AVS Special Member
 
Cris Moore's Avatar
 
Join Date: Oct 1999
Location: Oregon
Posts: 1,157
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
I did a test simular to what Xesdeeni mentioned trying.

I have a recording of "Ice Age" that I recorded off FOX with a MyHD 120.

A)
- I AM ABLE to ff/rew in the original unedited transport steam in MyHD.
- MProbe reports NO PCR jitter for this stream.

B)
- If I use H2 to strip NULLs, sub-channels, and other stuff out, leaving just the PAT, PMT, and the Video and Audio PIDs, I CAN NOT ff/rew during playback.
- MProble reports progressivly WORSE PCR jitter throughout the file.

C)
- If I use H2 to strip sub-channels and other stuff out, but select to PreserveBitRate, which leaves the PAT, PMT, Video and Audio PIDs, and everything else replaced with NULL packets, then I AM ABLE to ff/rew through the stream.
- MProbe reports NO PCR jitter for this stream.

It would seem the only way to correct the ff/rew problem would be to update the PCR, PTS and DTS information so that there is no, or relativily little, PCR jitter.

Cris Moore is online now  
post #644 of 2239 Old 02-28-2005, 06:51 AM
AVS Special Member
 
Xesdeeni's Avatar
 
Join Date: Mar 2003
Posts: 1,552
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:


Originally posted by TPeterson
I don't know the answer but it is already well known that H2 processing of TS to strip nulls "breaks" their FF/RW in MyHD.

It just seems like you (plural) are jumping to a conclusion. If removing the NULLs broke FF/RW, then why would some files work and others not, when they are sequentially from the same program!? (I had two more programs that exhibited this symptom over the weekend. In both these two cases, the FIRST file wouldn't FF/RW while the second would.)

I think removal of NULLs is a fairly constant operation. If it was the problem, no file without them would ever play with FF/RW. But many do. So I think there must be another, possibly related, issue.

Xesdeeni
Xesdeeni is offline  
post #645 of 2239 Old 02-28-2005, 06:59 AM
AVS Addicted Member
 
TPeterson's Avatar
 
Join Date: May 2002
Location: San Carlos, CA
Posts: 11,846
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 3 Post(s)
Liked: 16
Quote:


Originally posted by Xesdeeni
It just seems like you (plural) are jumping to a conclusion. If removing the NULLs broke FF/RW, then why would some files work and others not, when they are sequentially from the same program!? (I had two more programs that exhibited this symptom over the weekend. In both these two cases, the FIRST file wouldn't FF/RW while the second would.)

I think removal of NULLs is a fairly constant operation. If it was the problem, no file without them would ever play with FF/RW. But many do. So I think there must be another, possibly related, issue.

Xesdeeni

Did you read Cris' quote from Ron (dr1394) and his experiment with MProbe? The answer evidently is that stripping nulls can introduce PCR jitter but is not guaranteed to do so. If you have a series of files with nulls stripped it's quite possible that some of them will have enough jitter to mess up MyHD's FF/RW and others won't.
TPeterson is offline  
post #646 of 2239 Old 02-28-2005, 07:02 AM
Member
 
dtv_user's Avatar
 
Join Date: Dec 2003
Posts: 33
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Attention Cris Moore:

Cris the version of HDTVtoMpeg2 I'm using doesn't have the PreserveBitRate option and I was wondering where I could get the latest verion with this feature.

Thank you

dtv_user
Bob Harvey
dtv_user is offline  
post #647 of 2239 Old 02-28-2005, 07:14 AM
AVS Special Member
 
Xesdeeni's Avatar
 
Join Date: Mar 2003
Posts: 1,552
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:


Originally posted by TPeterson
Did you read Cris' quote from Ron (dr1394) and his experiment with MProbe? The answer evidently is that stripping nulls can introduce PCR jitter but is not guaranteed to do so. If you have a series of files with nulls stripped it's quite possible that some of them will have enough jitter to mess up MyHD's FF/RW and others won't.

Yes, but I'll admit to not understanding this fully.

In particular, when you record a sequence of files, my understanding is that these files are just broken (perhaps on the 188-byte boundary), and there should be no change in the data. So if I re-joined the files (with HDTVtoMPEG2, for example), the data would be identical, but in a single file.

So how could the PCR jitter be bad in one file and not in the next (or vise-versa)? It's the same stream of data!

Xesdeeni
Xesdeeni is offline  
post #648 of 2239 Old 03-01-2005, 11:28 AM
AVS Special Member
 
Xesdeeni's Avatar
 
Join Date: Mar 2003
Posts: 1,552
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
And to follow up that (apparently rhetorical) question:

Can the PCR jitter be repaired without restoring the NULLs?

(Assuming the answer is "yes," since some files without NULLs can FF/RW) Does the data need to be moved within the stream, or can it be repaired in place?

I.e. Can we create a utility that will correct PCR jitter on a file, preferably without adding NULLs, and also without copying the file?

Xesdeeni
Xesdeeni is offline  
post #649 of 2239 Old 03-01-2005, 11:33 AM
AVS Addicted Member
 
TPeterson's Avatar
 
Join Date: May 2002
Location: San Carlos, CA
Posts: 11,846
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 3 Post(s)
Liked: 16
Quote:


Originally posted by Xesdeeni
And to follow up that (apparently rhetorical) question:

Can the PCR jitter be repaired without restoring the NULLs?

(Assuming the answer is "yes," since some files without NULLs can FF/RW) Does the data need to be moved within the stream, or can it be repaired in place?

I.e. Can we create a utility that will correct PCR jitter on a file, preferably without adding NULLs, and also without copying the file?

Xesdeeni

Cris had already answered your question before you asked it: "It would seem the only way to correct the ff/rew problem would be to update the PCR, PTS and DTS information so that there is no, or relativily little, PCR jitter."
TPeterson is offline  
post #650 of 2239 Old 03-01-2005, 11:45 AM
AVS Special Member
 
Xesdeeni's Avatar
 
Join Date: Mar 2003
Posts: 1,552
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:


Originally posted by TPeterson
Cris had already answered your question before you asked it: "It would seem the only way to correct the ff/rew problem would be to update the PCR, PTS and DTS information so that there is no, or relativily little, PCR jitter."

That answers the first question (we think). But for those of us not familiar with the TS format, would that require moving data within the stream?

Xesdeeni
Xesdeeni is offline  
post #651 of 2239 Old 03-01-2005, 11:51 AM
AVS Addicted Member
 
TPeterson's Avatar
 
Join Date: May 2002
Location: San Carlos, CA
Posts: 11,846
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 3 Post(s)
Liked: 16
Quote:


Originally posted by Xesdeeni
That answers the first question (we think). But for those of us not familiar with the TS format, would that require moving data within the stream?

Xesdeeni

AIUI, the PCR, PTS, DTS, etc., are all data encoded in the existing packets and--in principle--could be rewritten as the file is copied, just as H2 does with other packet data (PMT/PAT). I think that's what Cris meant by "update."
TPeterson is offline  
post #652 of 2239 Old 03-01-2005, 12:20 PM
AVS Special Member
 
Xesdeeni's Avatar
 
Join Date: Mar 2003
Posts: 1,552
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:


Originally posted by TPeterson
AIUI, the PCR, PTS, DTS, etc., are all data encoded in the existing packets and--in principle--could be rewritten as the file is copied, just as H2 does with other packet data (PMT/PAT). I think that's what Cris meant by "update."

I understand that, but I'm asking whether they could be re-written without copying--in place: Seek through the files, find these items, modify as necessary. Copying allows you to move them within the stream, but takes up twice as much HD space.

Xesdeeni
Xesdeeni is offline  
post #653 of 2239 Old 03-01-2005, 12:49 PM
AVS Addicted Member
 
TPeterson's Avatar
 
Join Date: May 2002
Location: San Carlos, CA
Posts: 11,846
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 3 Post(s)
Liked: 16
Quote:


Originally posted by Xesdeeni
I understand that, but I'm asking whether they could be re-written without copying--in place: Seek through the files, find these items, modify as necessary. Copying allows you to move them within the stream, but takes up twice as much HD space.

Xesdeeni

You're assuming a second step and I'm assuming that the "update" would be part of H2's normal operation and, therefore, there would be no additional HDD space nor appreciable added time (aside from H2 coding time, that is ).
TPeterson is offline  
post #654 of 2239 Old 03-01-2005, 12:50 PM
AVS Special Member
 
Cris Moore's Avatar
 
Join Date: Oct 1999
Location: Oregon
Posts: 1,157
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:


Can the PCR jitter be repaired without restoring the NULLs?

I believe so.
Quote:


Does the data need to be moved within the stream, or can it be repaired in place?

The data does not need to be moved. The PCR, PTS, and DTS are fixed bytes lengths, so they could be updated in place.

From what I understand PCR's basically say that this particular byte will appear at this particular time in the stream. The PCR values are based on the CBR of the original stream. After editing with H2 and removing NULLs, sub-channels, and PSIP, the PCR values are no longer valid, ie. it's a VBR stream now. The time that they show up now (early) vs. the time they are SUPPOSE to show up (i.e. the PCR value) is what causes the jitter.

To update the PCR (and PTS\\DTS) values, the (now) variable bit rate would have to be determined between each PCR value and the new VBR used to calculate a new PCR value.

Well, that's the idea anyway.

Cris Moore is online now  
post #655 of 2239 Old 03-01-2005, 02:39 PM
AVS Special Member
 
Xesdeeni's Avatar
 
Join Date: Mar 2003
Posts: 1,552
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:


Originally posted by TPeterson
You're assuming a second step and I'm assuming that the "update" would be part of H2's normal operation and, therefore, there would be no additional HDD space nor appreciable added time (aside from H2 coding time, that is ).

Please let me apologize. I'm probably out of line in this thread, but the folks here seem to be the most knowledgable on the subject of streams like this and their problems in MyHD. I use H2 quite a bit (or I wouldn't be in this thread at all), mostly for archiving programs to DVDR, but my main source of NULL-less, single PID files is the FusionHDTV.

I was hoping to glean enough information from you guys to create a utility I could use when importing the streams into MyHD for viewing. But I would prefer not to have to fire up HDTVtoMPEG2 for each and every recording. Instead, I was thinking a utility that could fix the problem could be incorporated into the batch file I created that renames the Fusion files to the MyHD naming convention. The process is pretty simple now: open the Fusion drive (I use one for the Fusion and one for MyHD), double-click the batch file to rename the files (it finds any that need converting), and then import them into the MyHD control. Modifying the batch file to call a utility that also fixes the above would be fairly painless. But I'm concerned about the overhead (the wife gets annoyed with just that much of a delay) and hard drive wear-and-tear if I have to copy every program...thus my desire to do so in place.

So let me apologize again for not being clearer. I think this is a valuable feature for HDTVtoMPEG2, but my questions about in-place modification is related to my daily viewing habits.

Xesdeeni
Xesdeeni is offline  
post #656 of 2239 Old 03-01-2005, 03:57 PM - Thread Starter
AVS Special Member
 
balazer's Avatar
 
Join Date: Feb 2001
Location: Sunnyvale, CA
Posts: 3,317
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
I think you guys are misunderstanding the point of PCR jitter.

PCRs are defined in terms of a CBR stream. (Because, in fact, the MPEG-2 system spec only defines CBR transport streams. VBR transport streams are a sort of perversion of the standard.) A PCR is a time stamp that says when the packet appears if the stream is sent at a constant rate. PCR jitter, similarly, is defined in terms of a CBR interpretation of the stream, so it doesn't really make any sense to talk about the PCR jitter of a VBR stream. If you strip the nulls to generate a VBR stream, then you necessarily introduce PCR jitter (according to a CBR interpretation of the stream), because the relative positions of the PCR packets within the recording no longer reflect the PCR values.

It would be improper to "correct" the PCRs in a VBR stream to eliminate the jitter for two reasons: 1) you'd never be able to remux the stream again (except to do a full remux), and 2) the PCRs, PTSs, and DTSs are all defined in terms of the same program system clock. If you change the PCRs so that they are no longer consistent with the PTSs and DTSs, you would break the seeking of some players, and possibly make the stream unplayable by some decoders.

Ron is speculating that the MyHD seeking only works for VBR streams that are close to CBR, which would only be the case if the video coding was close to CBR.

The kinds of PCR corrections that TStoATSC can do are almost always very small corrections, due to the quantization error in packet placement. If you tried to "correct" the PCRs in a VBR stream to eliminate the jitter, you would introduce huge changes.

First, I am not convinced that Ron's speculation is correct, though it is possible. Regardless, the problem lies in the MyHD software, and I don't believe there's necessarily a way to "fix" VBR streams so that they always FF & RW in the MyHD.

The MyHD was designed primarily for CBR streams. It's nice that it will play VBR streams at all. Minimally, the software should be modified to seek in VBR streams, though not accurately, by doing it in the same way that seeking works in HDTVtoMPEG2: if you jump ahead one minute in a VBR stream, you'll actually jump ahead more than that, because HDTVtoMPEG2 is seeking as if the stream were 19.3 Mbps CBR.

If we want the problem fixed, we really need to push MIT to do it.

Another option would be to remux to a CBR stream at a rate lower than 19.3 Mbps. If Ron's speculation is correct, then such a stream would have no PCR jitter, and play in the MyHD correctly. I'll add an option to TStoATSC to specify the bit rate one of these days.

Perhaps Ron can chime in here and correct everything that I've just said incorrectly.
balazer is offline  
post #657 of 2239 Old 03-01-2005, 04:23 PM
AVS Special Member
 
RalphArch's Avatar
 
Join Date: Dec 2001
Location: Rockville MD
Posts: 2,753
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:


Originally posted by balazer
........
First, I am not convinced that Ron's speculation is correct, though it is possible. Regardless, the problem lies in the MyHD software, and I don't believe there's necessarily a way to "fix" VBR streams so that they always FF & RW in the MyHD.

The MyHD was designed primarily for CBR streams. It's nice that it will play VBR streams at all. Minimally, the software should be modified to seek in VBR streams, though not accurately, by doing it in the same way that seeking works in HDTVtoMPEG2: if you jump ahead one minute in a VBR stream, you'll actually jump ahead more than that, because HDTVtoMPEG2 is seeking as if the stream were 19.3 Mbps CBR.

If we want the problem fixed, we really need to push MIT to do it.
....................

.

Just a point regarding above - not that I understand it but -

the recorded files that I have that don't ff/rewind in MyHD also do not ff/rewind in TT2 - so it would appear to be broader than MyHD software
RalphArch is offline  
post #658 of 2239 Old 03-01-2005, 05:04 PM
Member
 
tecqboy's Avatar
 
Join Date: May 2004
Location: Glenfishpoint, Wisconsin
Posts: 75
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
For What It's Worth... I use MyHD to capture, but I do not use it for playback. I use the Moonlight Elecard MPEG player. Streams edited with H2 vers 1.10.5 will FFW and RW on this software player.
tecqboy is offline  
post #659 of 2239 Old 03-01-2005, 05:19 PM
AVS Addicted Member
 
TPeterson's Avatar
 
Join Date: May 2002
Location: San Carlos, CA
Posts: 11,846
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 3 Post(s)
Liked: 16
Ralph, et. al--

For a pretty clear explanation of the MPEG-2 alphabet soup, I recommend Michael Isnardi's presentation found here: <<a href="http://www1.leitch.com/resources/tutorials/mpeg-2Systems.pdf" target="_blank">http://www1.leitch.com/resources/tut...g-2Systems.pdf>.

N.B., slides 20-30 that discuss synchronization and the purposes of PCR, DTS, and PTS. After reading this, I agree with Jacob that "PCR jitter" only has proper meaning in a CBR context. Also, it's not at all clear to me that any of these values needs "fixing" because they are instructions and references for proper rendition of the program and should be invariant with the TS conversion to a bastardized VBR format, I think.
TPeterson is offline  
post #660 of 2239 Old 03-01-2005, 06:44 PM
AVS Special Member
 
RalphArch's Avatar
 
Join Date: Dec 2001
Location: Rockville MD
Posts: 2,753
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Thanks Terry - it did clear it up somewhat for me even though most of those slides are way above my level of understanding
RalphArch is offline  
Reply Home Theater Computers

User Tag List

Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off