TSCV Entry Point Error??

4th Nov 2001 14:25 #1

Member

I keep getting the following errors when creating a bin/cue, can someone please explain?

requested entry point (id=entry1-1) at 530.000000, closest possible entry point at 0.000000
requested entry point (id=entry1-2) at 1200.000000, closest possible entry point at 0.000000
entry point 'entry1-2' falls into same sector as previous one!
requested entry point (id=entry1-3) at 1762.000000, closest possible entry point at 0.000000
entry point 'entry1-3' falls into same sector as previous one!
requested entry point (id=entry1-4) at 2800.000000, closest possible entry point at 0.000000
entry point 'entry1-4' falls into same sector as previous one!

Thanks!

Quote

4th Nov 2001 14:36 #2

JJamez

Member

I had this exact problem and gave up on it a few weeks back so as not to drive myself completely insane...

I'm still curious what the solution is though.

JJ

Quote

4th Nov 2001 15:00 #3

vitualis

Member

Your MPEG does not have regular mpeg sequence headers. No headers, no entrypoints.

I wrote on how this can be fixed here: http://www.geocities.com/medinotes/vcd/chapters.html

Regards.

Michael Tam
w: Morsels of Evidence

Quote

5th Nov 2001 05:26 #4

ya_jai

Member

How did you encode your mpeg file? If you use TMPGenc you need to close GOP in GOP structure tab. But if you use VCDimager the current version (0.7.10 up) and enable "update scan offset" I don't think you will have this problem.
You can try demux mpeg file in TMPGenc then mux with bbMPEG. That should help.

Quote

5th Nov 2001 09:28 #5

KoalaBear

Member

TeflonDon --

Chapter points are compiled somewhat differently in MPEG-1 and MPEG-2. The [S]VCD standard imposes additional constraints on top of those, and authoring systems vary in the way they allow those chapter points to be referenced.

In MPEG-1, a chapter point consists of a sequence header followed by a GOP header followed by a closed GOP. The first GOP in a bitstream meets this requirement, which is why it's always accessible. Any good MPEG-1 encoder (i.e., Panasonic) will compile additional chapter points that meet these requirements wherever you desire to place them.

In MPEG-2, the syntax is more relaxed. A stream can be entered on any I-frame preceded by a sequence header, and the GOP strictly speaking doesn't even have to be closed. A good MPEG-2 encoder (i.e., CinemaCraft) will compile chapter points as a sequence header followed by a closed GOP wherever you tell it to place them.

Now, the [S]VCD specification imposes the additional requirement that chapter points must be aligned to packet boundaries in order to be mapped to a physical disc sector (the so-called Access Point Sector or APS). This means that the packet immediately preceding the chapter point must be padded if necessary to achieve this alignment. A good [S]VCD-aware multiplexer (Philips VCDMUX [MPEG-1], Enreach MPG2MPS [MPEG-2]) will handle this kind of packet alignment correctly.

Finally, there are differences in the way authoring programs reference the locations of chapter points. Philips VCD2TK is apparently keyed to the timecode embedded in the GOP header, allowing you to address a chapter point in hh:mms:ff format. VCDImager on the other hand is apparently keyed to the Presentation Time Stamp (PTS) of particular frames expressed as an offset from time zero.

While I like and use VCDImager myself, I find the PTS method of chapter reference to be problematic. However, assuming the chapter points themselves are properly coded, it should only take a few tweak-and-burn cycles to get the XML code to agree.

Vitualis --

(1) What's the rationale behind embedding sequence headers throughout the bitstream if they're only required under specific circumstances? Panasonic inserts them where they're necessary, so isn't this just a pure waste of bandwidth?

(2) In your chaptering tutorial you suggest closing all GOPs rather than just the ones that constitute entry points. Closing a GOP alters its structure by omitting the leading and trailing B-frame pairs in order to ensure that pictures aren't predicted from references outside that GOP, which wastes a large fraction of compression potential. Again, closed GOPS are needed only under specific circumstances, so what's the rationale behind closing all of them?

Quote

5th Nov 2001 11:07 #6

TeflonDon

Member

Ok, that is solved. Now, I get the following messages:

scanning mpeg segment item "menu-0" for scanpoints...
mpeg stream will be padded on the fly -- hope that's ok for you!
autopadding requires to insert additional 258612 zero bytes into MPEG stream (due to 937 unaligned packets of 938 total)
scanning mpeg segment item "menu-1" for scanpoints...
mpeg stream will be padded on the fly -- hope that's ok for you!
autopadding requires to insert additional 109020 zero bytes into MPEG stream (due to 395 unaligned packets of 396 total)
scanning mpeg segment item "menu-2" for scanpoints...
mpeg stream will be padded on the fly -- hope that's ok for you!
autopadding requires to insert additional 109020 zero bytes into MPEG stream (due to 395 unaligned packets of 396 total)
scanning mpeg sequence item "sequence-1" for scanpoints...
mpeg stream will be padded on the fly -- hope that's ok for you!

Please help!
Thanks

Quote

5th Nov 2001 13:50 #7

vitualis

Member

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>
On 2001-11-05 16:28:20, KoalaBear wrote:
While I like and use VCDImager myself, I find the PTS method of chapter reference to be problematic. However, assuming the chapter points themselves are properly coded, it should only take a few tweak-and-burn cycles to get the XML code to agree.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

I believe (could be wrong) the reason why hvr chose PTS rather than the other way is that the timing in GOP can be quite incorrect. Not sure about what you mean by the "tweak-and-burn" cycles. In the vcdxbuild log, it tells you exactly where the entrypoint gets placed. IF you have headers before each GOP, you should be able to place an entrypoint within about 1/4 of a second of a targeted frame and exactly on an I-frame.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>(1) What's the rationale behind embedding sequence headers throughout the bitstream if they're only required under specific circumstances? Panasonic inserts them where they're necessary, so isn't this just a pure waste of bandwidth? </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Have you actually tried it?? It adds no more than about 100 kB over 700MB of video. The increase in bitrate is negligible. I agree that if you AREN'T going to use entrypoints, there is no reason to spend the effor adding the sequence headers in.

Also, Panasonic cannot add the headers "where necessary" if you don't know where to set them (i.e., you can't always predict where you want the chapters to go BEFORE you've encoded the video). You can use MPEG Sequence Maker to just put headers at only specific times but this involves a lot more work with no real gain (unless you are pushing your media to the limit of kilobytes of capacity). Having a header before each GOP just makes it much more flexible to work with.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>(2) In your chaptering tutorial you suggest closing all GOPs rather than just the ones that constitute entry points. Closing a GOP alters its structure by omitting the leading and trailing B-frame pairs in order to ensure that pictures aren't predicted from references outside that GOP, which wastes a large fraction of compression potential. Again, closed GOPS are needed only under specific circumstances, so what's the rationale behind closing all of them?</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

I explained it in the article. It would be preferable to not force the GOPs to be all closed but TMPGEnc will sometimes go AWOL and not close a GOP for extended periods of time (in the range of tens of seconds). Again, you cannot always predict WHERE you want chapters BEFORE encoding. You are pretty much stuffed then if you want to put a chapter in the middle of one of these sections. Furthermore, I believe that VCD2.0 recommends that GOPS be closed at a maximum of 2 seconds.

Regards.

_________________
Michael Tam

<font size=-1>[ This Message was edited by: vitualis on 2001-11-05 20:53:17 ]</font>

Quote

5th Nov 2001 13:58 #8

vitualis

Member

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>
On 2001-11-05 18:07:57, TeflonDon wrote:
Ok, that is solved. Now, I get the following messages:

scanning mpeg segment item "menu-0" for scanpoints...
mpeg stream will be padded on the fly -- hope that's ok for you! ...[edit]...</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

You need to remultiplex your MPEG. If you use TMPGEnc to remux (or cut/merge), make sure it set it to MPEG-1 Video-CD setting rather than the default "Auto".

If you use bbMPEG, I think you have to check the box that says "pad VCD audio".

Good luck.

Regards.

Michael Tam
w: Morsels of Evidence

Quote

5th Nov 2001 14:16 #9

TeflonDon

Member

Thanks, I have followed your instructions using TMPGEnc and recieved the following error:

"294469s packets cause buffer underflow.

The MPEG file might cause error when played."

FYI,I originally encoded using the VCD template with a bitrate of 1400.

Quote

5th Nov 2001 15:37 #10

vitualis

Member

Okay, so you are making an XVCD (that is a non-standard VCD bitrate).

You will have to remux with TMPGEnc using the MPEG-1 Video-CD (non-standard) setting instead of the normal one (otherwise you get the problem you just posted).

This should (hopefully) fix everything.

Regards.

Michael Tam
w: Morsels of Evidence

Quote

6th Nov 2001 01:25 #11

KoalaBear

Member

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>I believe (could be wrong) the reason why hvr chose PTS rather than the other way is that the timing in GOP can be quite incorrect.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

As long as we're theorizing, my guess would be that because GOP headers are required in MPEG-1 but not MPEG-2, you would need to devise a header-independent method of chapter reference in order to handle VCD and SVCD using the same code. Addressing chapters by PTS reference would accomodate this, but it's clumsy and difficult to use.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>IF you have headers before each GOP, you should be able to place an entrypoint within about 1/4 of a second of a targeted frame and exactly on an I-frame.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

It depends on whether you're talking about MPEG-1 or MPEG-2. In MPEG-1, if the I-frame in question is part of an open GOP (which the majority of time it is) it's not a legal entry point. If you slap a sequence header on every GOP you might find an entry point near the one you specified, but it's not guaranteed unless you close *all* the GOPs, which means you'd essentially be generating 3600+ chapter points per hour when you only need perhaps six.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>Have you actually tried it?? It adds no more than about 100 kB over 700MB of video.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

No. Why would somebody needlessly insert thousands of sequence headers into a program that has only a dozen chapters?

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>Also, Panasonic cannot add the headers "where necessary" if you don't know where to set them (i.e., you can't always predict where you want the chapters to go BEFORE you've encoded the video).</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

I've never known anyone to have the problem of not knowing where they want the chapter points to be set. For simplicity, assume you want the chapter points to be set on the same frame(s) as the DVD it was ripped from. All you have to do is locate the appropriate frame numbers, mark those frames as chapters, and the encoder will generate legal entry points for each of them.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>It would be preferable to not force the GOPs to be all closed but TMPGEnc will sometimes go AWOL and not close a GOP for extended periods of time (in the range of tens of seconds).</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Actually, that's normal behavior. Apart from chapter points the only time you should encounter a closed GOP is whenever a scene change is detected. If you close all the GOPs as a matter of course, you're going to need a higher average bitrate to compensate for the loss of compression efficiency.

In the case of a constrained bitrate (i.e., VCD-compliant MPEG-1) this will almost certainly have a negative impact on picture quality.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>Again, you cannot always predict WHERE you want chapters BEFORE encoding. You are pretty much stuffed then if you want to put a chapter in the middle of one of these sections.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Again, this statement completely defies logic. Perhaps what you mean is that you can't predict where the I-frames will be inserted into the bistream by the encoder, ergo you can't predict where your entry points will be.

Any encoder that supports chaptering (Panasonic, CCE) allows you to specify which frames you want to make into chapter points. When the encoder reaches one of these frames, it terminates the GOP in progress, inserts the necessary headers, and constructs a closed GOP using the marked frame as the I-frame for that GOP.

In other words, whether you can predict the location of I-frames on a statistical basis is meaningless. Chaptering allows you to specify exactly which frames to convert into legal entry points without regard to the structure of past or future GOPs.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>Furthermore, I believe that VCD2.0 recommends that GOPS be closed at a maximum of 2 seconds.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

I don't think so, but you're welcome to show us the Holy White Book anyway.

Quote

6th Nov 2001 03:49 #12

vitualis

Member

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>
On 2001-11-06 08:25:49, KoalaBear wrote:
As long as we're theorizing, my guess would be that because GOP headers are required in MPEG-1 but not MPEG-2, you would need to devise a header-independent method of chapter reference in order to handle VCD and SVCD using the same code. Addressing chapters by PTS reference would accomodate this, but it's clumsy and difficult to use.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Firstly, I wasn't theorising which you seem like doing instead of experience. I was trying to remember what hvr told me once. Perhaps it would make more sense to you if you talked to hvr himself. I got that info from HIM. I'm sure that he had a good reason for doing it that way.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>
It depends on whether you're talking about MPEG-1 or MPEG-2.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

I was referring to MPEG-1.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>In MPEG-1, if the I-frame in question is part of an open GOP (which the majority of time it is) it's not a legal entry point. If you slap a sequence header on every GOP you might find an entry point near the one you specified, but it's not guaranteed unless you close *all* the GOPs, which means you'd essentially be generating 3600+ chapter points per hour when you only need perhaps six.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Fair enough, but I was suggesting closing all GOPs remember? And what exactly is wrong with generating 3600+ potential chapter points?

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>No. Why would somebody needlessly insert thousands of sequence headers into a program that has only a dozen chapters? </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Because, it adds less than a second over 80 minutes of video and instead of being hamstrung to a number of defined points, I can choose to add an entrypoint anywhere I wish to a definition of about a quarter of a second. Plus there are compatibility issues (read below).

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>I've never known anyone to have the problem of not knowing where they want the chapter points to be set. For simplicity, assume you want the chapter points to be set on the same frame(s) as the DVD it was ripped from. All you have to do is locate the appropriate frame numbers, mark those frames as chapters, and the encoder will generate legal entry points for each of them. </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Quite simple. Not everybody makes DVD rips all the time... For home videos I tend not to go through my source (which would be over several AVI files) and count frame numbers for chapters before I encode. Stop thinking from such a narrow point of view.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>Again, this statement completely defies logic. Perhaps what you mean is that you can't predict where the I-frames will be inserted into the bistream by the encoder, ergo you can't predict where your entry points will be.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

As above. Stop just thinking of DVD rips. There are lots of reasons why people make VCDs and encode MPEG-1.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>Any encoder that supports chaptering (Panasonic, CCE) allows you to specify which frames you want to make into chapter points. When the encoder reaches one of these frames, it terminates the GOP in progress, inserts the necessary headers, and constructs a closed GOP using the marked frame as the I-frame for that GOP. </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

All very true. However, the Panasonic MPEG encoder plug-in always crashes on me when I tried setting the forced intra frames and from EXPERIENCE, adding sequence headers in front of every GOP not only worked, but made the job easier. Also, as I stated before, for compatibility reasons, it's a good idea to add a sequence header before each GOP (read below).

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>Furthermore, I believe that VCD2.0 recommends that GOPS be closed at a maximum of 2 seconds.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

There are enough references to White Book on the net that you can look it up yourself. You can BUY it from Philips if you really want to.

BTW, you do realise that Panasonic encodes by closing all GOPs be default?

And you do of course realise that Philips DVD players (as in Philips the main developer of VCD and wrote the White Book specs) do not play VCDs properly if they DON'T have a sequence header before each GOP (cannot FFW or REW).

Also, I make all my recommendations on that article FROM EXPERIENCE -- not out of any sort of love for specifications. Logic would dictate that GOPs open would be a better setting for TMPGEnc -- until I got a few posts from people who were then subsequently stuffed when they wanted to make chapters.

Also, from experience, the quality difference between GOPs open and closed is not really signficicant or even noticeable with TMPGEnc. In lieu of these facts, I recommend having them closed if you WANT TO MAKE CHAPTERS (which was the point of the article).

Similarly, in light of the problem with PHILIPS (of all brands!) DVD players, I think that putting in a sequence before each GOP isn't a bad idea. It's not going to affect playback in any negative way and barely even makes the file larger. Hmm... some potential positives, no negatives. That's why I suggest that you do it.

Regards.

_________________
Michael Tam

<font size=-1>[ This Message was edited by: vitualis on 2001-11-06 11:03:15 ]</font>

Quote

6th Nov 2001 07:53 #13

KoalaBear

Member

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>
<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>I believe (could be wrong) the reason why hvr chose PTS rather than the other way is that the timing in GOP can be quite incorrect.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>
Firstly, I wasn't theorising which you seem like doing instead of experience.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Uh huh. I see.

You seem to believe that MPEG encoders insert I-frames twice a second for the purpose of timekeeping. They do not. They insert I-frames periodically because the motion compensation process accumulates errors that would progressively degrade the image if they were allowed to propagate indefinitely.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>I'm sure that he had a good reason for doing it that way.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

I'm sure he did. But that doesn't make the method elegant, efficient or easy to understand and to use.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>And what exactly is wrong with generating 3600+ potential chapter points?</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Because if you only need twelve, the other 3588 are simply a waste of resources. But the extra sequence headers aren't the problem so much as the closed GOPs. Closing a GOP alters its structure in a way that compromises compression efficiency. Do you in fact understand the difference between the two?

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>I can choose to add an entrypoint anywhere I wish to a definition of about a quarter of a second.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Whoop-de-doo. I can add an entrypoint anywhere I wish to the accuracy of a single frame. That's what a "chapter mark" is intended for.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>Not everybody makes DVD rips all the time... </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>
Quite frankly I don't make DVD rips at all. It was an example that illustrated a point, i.e., that most people have a very specific idea of where they want their chapter points to be in advance. I apologize if the example was too technical to understand.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>All very true. However, the Panasonic MPEG encoder plug-in always crashes on me when I tried setting the forced intra frames ... </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

... so the logical conclusion is that people would be well-advised to follow your example even if it's a ludicrously inefficient means to an end?

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>There are enough references to White Book on the net that you can look it up yourself. You can BUY it from Philips if you really want to. </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Just like you did, right?

I notice that whenever somebody points out a weakness in your reasoning you invoke the authority of documents you've never read in order to give the impression that you're relaying an established fact.

If the VCD 2.0 specification demands at least one closed GOP every two seconds (a ridiculous supposition if you think about it) you should be able to provide a link to the document that says so, right?

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>BTW, you do realise that Panasonic encodes by closing all GOPs be default? </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Not that I'm aware of, no. But then you did say your computer crashes whenever you try to use it properly. What's your point?

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>Also, I make all my recommendations on that article FROM EXPERIENCE -- not out of any sort of love for specifications.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

...let alone any healthy respect for the facts.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>Logic would dictate that GOPs open would be a better setting for TMPGEnc -- until I got a few posts from people who were then subsequently stuffed when they wanted to make chapters.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Vague anecdotes about people who very likely didn't know what they were doing to begin with isn't a "proof" of anything.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>In lieu of these facts, I recommend having them closed if you WANT TO MAKE CHAPTERS (which was the point of the article).</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Precisely. "In lieu of" means "instead of," you know. But I understand what you meant. Your system crashes whenever you try to insert chapter points using Panasonic, therefore you recommend people close all their GOPs in TMPGenc.

Riiiiight.

But if you want to continue the conversation is it necessary to do all this quoting? I'm sure you can construct a coherent argument to support your ideas without seeing how broadly you can take a series of statements out of context.

<font size=-1>[ This Message was edited by: KoalaBear on 2001-11-06 15:06:35 ]</font>

Quote

7th Nov 2001 02:39 #14

vitualis

Member

Let me firstly point out that I find it rather offensive when you twist my arguements out of context.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>
You seem to believe that MPEG encoders insert I-frames twice a second for the purpose of timekeeping. They do not. They insert I-frames periodically because the motion compensation process accumulates errors that would progressively degrade the image if they were allowed to propagate indefinitely. </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

I know exact what I-frames are used for I did not in the slightest suggest that. I don't even know where you came up with that crap.

The timing in the GOP can be incorrect in terms of the REAL playback time of the clip -- thus, it isn't a good choice for VCDImager to work on. For example, if I CUT the clip, the timings in the GOP for the second half will be completely incorrect.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>I'm sure he did. But that doesn't make the method elegant, efficient or easy to understand and to use. </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

What is there to understand for the end user exactly? If I want to put an entrypoint at the 120 second mark, I write "120" in the XML. If I want to put an entrypoint at 1000 second mark, I write "1000" in the XML.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>Because if you only need twelve, the other 3588 are simply a waste of resources.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Pointless theoretical arguement. "WASTE OF RESOURCES". Which resource are you talking about exactly? Disc capacity? The increase in size is neligible.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE> But the extra sequence headers aren't the problem so much as the closed GOPs. Closing a GOP alters its structure in a way that compromises compression efficiency. Do you in fact understand the difference between the two?</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Perhaps you should write to Panasonic and tell them that for the next version of Panasonic MPEG Encoder then. I know what closing GOPs does.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>Quite frankly I don't make DVD rips at all. It was an example that illustrated a point, i.e., that most people have a very specific idea of where they want their chapter points to be in advance. I apologize if the example was too technical to understand. </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Exactly MY point. How can you illustrate a point when you yourself DON'T do it? You presume to understand all the intricacies of DVD ripping even though you DON'T even do it? YOU HAVE NO EXPERIENCE IN THIS AT ALL DO YOU? And you sit here pretending to be the bearer of wisdom. I have done enough encoding to know that even if you do have a good idea on where you want chaptermarks BEFORE encoding, it won't necessarily be in exactly the same place after you encode.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>... so the logical conclusion is that people would be well-advised to follow your example even if it's a ludicrously inefficient means to an end?</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Once again, where is it inefficient. From my experience with Panasonic, I cannot reliable place entrypoints BEFORE encoding. Thus, I have to place them AFTERWARDS. Do you understand this simple fact?

The only way to place them AFTERWARDS is to use MPEG SEQUENCE MAKER. Have you even used this before?? Now, you can choose SPECIFIC times to put the headers in (which involves a great deal of typing), or place them in front of every GOP which is the DEFAULT setting (thus takes the least time). Since there is NO particular DETRIMENT to placing them in front of all GOPs and there indeed are benefits, I suggest you just use the default.

What part of this simple explanation do you not understand??

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>you invoke the authority of documents you've never read in order to give the impression that you're relaying an established fact.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Again, there are enough documents on the net referring to this that I don't need to have BOUGHT White Book. For example, I know that White Book needs the video stream to be at 352x288 framesize for PAL. I don't need to have read it to know this.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE><TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>BTW, you do realise that Panasonic encodes by closing all GOPs be default? </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Not that I'm aware of, no. But then you did say your computer crashes whenever you try to use it properly. What's your point?</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

What exactly is your point? My point is that you say that closing the GOPs makes the encoding horribly inefficient. Yet somehow, Panasonic produces some of the best MPEG-1 encoded video at VCD bitrates with closed GOPs.

Panasonic is one of the best MPEG-1 encoders (as you seem seem to agree with) for VCD in terms of compliance. It closes all GOPs.

LSX is another which also good on compliance. It too closes all GOPs (and places a header before each one) by default on the VCD setting.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>...let alone any healthy respect for the facts.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

You seem to believe that theory alone is all that's involved. You make me laugh. Important as it is, working knowledge in this field is just as important if not more so. Theory alone will not make you a VCD.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>Vague anecdotes about people who very likely didn't know what they were doing to begin with isn't a "proof" of anything.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Hmm... good God. You're psychic! You must have been looking over my shoulder when I was corresponding with those people via e-mail? Or perhaps you're hacking into my PC, hey?

It is rather presumptive of you to call it "vague anecdoetes". The results from the people I talked to were hardly "vague".

I fully agree that open GOPs will theoretically yield better quality. I don't deny this. I don't believe I have.

FROM EXPERIENCE though, I see little if ANY loss of quality with TMPGEnc with the setting of closing the GOPs. Can you understand this? Theory is ONE thing. Practical experience is ANOTHER. With my eyes, this setting has LITTLE IMPACT on quality with TMPGEnc.

Not having the GOPs closed can have a detrimental effect on chapter placement though. Now unless you know better and are calling the person I corresponded with a LIAR, the simple expediant solution is to simply close the GOPs.

Despite all your moaning about how this ruins MPEG-1, it certain doesn't seem like it does to me, with TMPGEnc, Panasonic or LSX.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>"In lieu of" means "instead of,"</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

I bow to your superior literary knowledge.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>Your system crashes whenever you try to insert chapter points using Panasonic, therefore you recommend people close all their GOPs in TMPGenc. </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

However, I suggest you learn to read. I in no way reached my conclusion with TMPGEnc based on Panasonic.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>But if you want to continue the conversation is it necessary to do all this quoting? I'm sure you can construct a coherent argument to support your ideas without seeing how broadly you can take a series of statements out of context. </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Well it is a litte bit difficult when I'm continually taken out of context.

Furthermore, I suggest you should stop and gain some experience in doing things before arguing points you have no first hand knowledge of.

Regards.

_________________
Michael Tam

<font size=-1>[ This Message was edited by: vitualis on 2001-11-07 09:50:52 ]</font>

Quote

7th Nov 2001 03:17 #15

vitualis

Member

You stated before that you want a more coherent argument? I'll answer the questions you asked initially AGAIN.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>(1) What's the rationale behind embedding sequence headers throughout the bitstream if they're only required under specific circumstances? Panasonic inserts them where they're necessary, so isn't this just a pure waste of bandwidth? </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

You've got a good point, but from experience, Panasonic often CRASHES when I try to use the forced intra frame setting. Thus, if I want to use this encoder, the forced intra frame functionality is not an option. From my experience with CCE, I don't have this problem so you can rightly use CCE to set the chapter marks. CCE, is however, a poor MPEG-1 encoder at VCD bitrates.

In terms of the "waste of bitrate", it is a valid concern but is NOT born out by experience. Over an 800MB file (i.e., 80 minuts of VCD video), the addition of the headers adds no more than about 100 kB to the video elemental stream. This equates to no more than a second in terms of disc capacity. Considering the time involved in only setting specific mpeg sequence headers, it is simply much more expedient to place them before all.

Correction: a quick test showed that it is closer to 300 kb increase in size in the MPEG which is < 2s of capacity. However, this is the raw MPEG size. I would suspect that the actually difference it would make once as a VCD image (CUE/BIN) would be minor. Even if it wasn't, the loss of 2s of capacity is hardly a signficant waste in bitrate

Furthermore, there is also the added benefit that if a sequence header is placed before each GOP, the Philips DVD player will be able to use the functions of FFW and REW.

It should be noted that several other common MPEG-1 encoders inserts an MPEG sequence header by default before each GOP for VCD standard MPEG-1 (LSX, CCE and TMPGEnc).

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>(2) In your chaptering tutorial you suggest closing all GOPs rather than just the ones that constitute entry points. Closing a GOP alters its structure by omitting the leading and trailing B-frame pairs in order to ensure that pictures aren't predicted from references outside that GOP, which wastes a large fraction of compression potential. Again, closed GOPS are needed only under specific circumstances, so what's the rationale behind closing all of them?
</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

True. However, there is a problem with chapter placement in TMPGEnc encoded streams if the GOP setting is left on open. TMPGEnc can often encode sections of video with the GOP left open for tens of seconds. If a chapter mark is desired to be placed within this section after encoding (i.e., forced intra-frame settings not used), it is impossible (at least not possible in a compliant way -- VCDImager has a "relaxed" option for this but the resultant disc will play problematically on many players).

With TMPGEnc set to closed GOPs, this apparent problem seems solved.

In terms of the possibility of less efficiently encoded video, and thus poorer quality, it doesn't appear to be the case from experience. If quality is worse, it is only so by a small margin.

It should be noted that several other encoders encode MPEG-1 for VCD with closed GOPs by default (Panasonic, LSX and ?Xing).

Happy?

Regards.

_________________
Michael Tam

<font size=-1>[ This Message was edited by: vitualis on 2001-11-07 11:15:33 ]</font>

Quote

7th Nov 2001 16:22 #16

KoalaBear

Member

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>Let me firstly point out that I find it rather offensive when you twist my arguements out of context.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

My policy is to play nice on round one, then do whatever the other guy did on the previous round. That means if you quote me out of context, I'll quote you out of context, you play nice, I play nice, and so forth. It's an effective way to bring a conversation back on track.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>What is there to understand for the end user exactly? If I want to put an entrypoint at the 120 second mark, I write "120" in the XML. If I want to put an entrypoint at 1000 second mark, I write "1000" in the XML.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Because chapter points don't usually (okay, almost never) occur on second boundaries. Say the frame that marks your entry point occurs at 1:06:37:18 -- what's the presentation time stamp for that frame going to be? 4034? Nope, that's several frames in the past. 4035? Nope, that may be an I-frame but there's no sequence header there. 4034.600600? Possibly, assuming the PTS is calculated using drop-frame timecode, otherwise no.

It's an unwieldy and imprecise method of chapter reference at best.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>Perhaps you should write to Panasonic and tell them that for the next version of Panasonic MPEG Encoder then. I know what closing GOPs does.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

For the moment, let's put aside the question of whether it's a good idea or not. Tell me how you arrived at the conclusion that Panasonic, let alone most MPEG-1 encoders, close all their GOPs by default.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>I have done enough encoding to know that even if you do have a good idea on where you want chaptermarks BEFORE encoding, it won't necessarily be in exactly the same place after you encode.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

How do you figure that? Tell an encoder to put a chapter mark at frame 3076, it compiles a legal entry point at frame 3076. If you can't figure out the Presentation Time Stamp for that frame in order to actually make use of it, that's a problem with the authoring program and not the MPEG encoder.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>From my experience with Panasonic, I cannot reliable place entrypoints BEFORE encoding. Thus, I have to place them AFTERWARDS. Do you understand this simple fact?</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Most definitely. You can't get Panasonic to compile a chapter point without crashing, so you turn every GOP into a chapter point, and take the one that's closest to the place you intended it to be that you can guess the PTS for. What I don't understand is why you'd take a such a crude workaround, write a 'how-to' guide out of it, and haughtily suggest that people take heed of it anytime they have a question about chapter points, as you've done here.

I mean, jeezus, Vitualis, can't you just fix your damned PC?

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>Again, there are enough documents on the net referring to this that I don't need to have BOUGHT White Book. For example, I know that White Book needs the video stream to be at 352x288 framesize for PAL. I don't need to have read it to know this.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

No, Vitualis, there are no documents on the web that say fixed-length GOPs are a condition of White Book compliance or that the VCD 2.0 specification requires you to insert a closed GOP at least once every two seconds. You simply made them up.

If I'm incorrect, go ahead and show us the hyperlinks. I'm not ashamed to be proven wrong. Are you?

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>Panasonic is one of the best MPEG-1 encoders (as you seem seem to agree with) for VCD in terms of compliance. It closes all GOPs.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Apart from the obvious logical flaws in this statement, I'm left wondering exactly how you came to know this particular item as a fact. Was it written in the White Book or the VCD 2.0 specification?

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>It is rather presumptive of you to call it "vague anecdoetes". The results from the people I talked to were hardly "vague".</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

No, you're quite right. They were utterly irrelevant.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>Well it is a litte bit difficult when I'm continually taken out of context.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Remember the golden rule.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>Furthermore, I suggest you should stop and gain some experience in doing things before arguing points you have no first hand knowledge of.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

And I suggest you learn the critical thinking skills necessary to argue your way out of a wet paper bag. I'm well aware that I'm not an easy guy to sustain a debate with; I'm smart and I'm not afraid to lose. But I think everybody gains something from a discussion like this: we just might arrive at the truth.

Quote

7th Nov 2001 16:32 #17

KoalaBear

Member

Now, I will also respect your intelligence with a coherent followup to your coherent argument (isn't tit-for-tat fun?):

If Panasonic crashes when you try to compile a chapter mark, you might consider fixing your computer rather than writing a 'how-to' guide based on a kludge.

It's entirely possible to specify a chapter mark to the accuracy of a single frame. This is in fact what most people are trying to do. If you can help them achieve that goal that's great, but if you tell them that they can only get within a quarter second of any chapter mark (and only then if they make every GOP a potential entry point) you should at least make the disclaimer that while it may be an example of shamefully poor craftsmanship, it will certainly work for them in a pinch.

But compiling chapter marks, once you find out how, is the easy part. Figuring out how to reference them by their Presentation Time Stamp (PTS) is not.

Now, as for the closed GOPs. I'm afraid that your explanation regarding this was so obtuse that I'm having difficulty understanding it at all:

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>there is a problem with chapter placement in TMPGEnc encoded streams if the GOP setting is left on open. TMPGEnc can often encode sections of video with the GOP left open for tens of seconds. If a chapter mark is desired to be placed within this section after encoding (i.e., forced intra-frame settings not used), it is impossible (at least not possible in a compliant way -- VCDImager has a "relaxed" option for this but the resultant disc will play problematically on many players).

With TMPGEnc set to closed GOPs, this apparent problem seems solved.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

What?

1. TMPGenc can encode several seconds worth of open GOPs at a stretch.

Check. This is normal behavior for an MPEG encoder. It's not a bug.

2. Thus if you want to make a chapter mark in the middle of this stretch afterward, you can't.

Check. A chapter mark consists of a sequence header followed by a GOP header followed by a closed GOP. You haven't inserted any of those here.

3. (i.e., forced intra-frame settings not used), it is impossible (at least not possible in a compliant way ... [) to compile a chapter mark afterwards?]

Check. If you're going to divide your MPEG program into chapters, an I-frame by itself isn't enough.

5. But when you force all the GOPs to close (and insert the sequence headers afterward, right?) chances are you'll find a GOP you can jump to.

Got it.

When you compile a "forced I-frame" in Panasonic you get a chapter mark. When you compile a chapter mark in CCE you get a chapter mark. If TMPGenc doesn't handle chaptering properly, why not use an MPEG encoder that does?

The problem isn't the workaround required to make TMPGenc do something it's apparently not designed to do, the problem is that you'd suggest this behavior is normal and good coding practice to boot.

Quote

8th Nov 2001 02:35 #18

vitualis

Member

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>Because chapter points don't usually (okay, almost never) occur on second boundaries. Say the frame that marks your entry point occurs at 1:06:37:18 -- what's the presentation time stamp for that frame going to be? 4034? Nope, that's several frames in the past. 4035? Nope, that may be an I-frame but there's no sequence header there. 4034.600600? Possibly, assuming the PTS is calculated using drop-frame timecode, otherwise no. </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

1:06:37:18 (25 fps?) = 3997.72 seconds... I don't know how YOU came up with those numbers. Perhaps you don't know how to convert hh:mms:ff to seconds?? I would be very disapointed with you if that was the case. Even if that is not a valid chapter location, VCDImager will find the closest one. If you do know the exact frame, then it is just as easy to work out the exact time.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>It's an unwieldy and imprecise method of chapter reference at best.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Unwieldy yes. But imprecise?? I've used this enough times to know that it is frame accurate. It is only imprecise for those people who can't do the simple mathematics involved to convert hh:mms:ff to seconds.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>For the moment, let's put aside the question of whether it's a good idea or not. Tell me how you arrived at the conclusion that Panasonic, let alone most MPEG-1 encoders, close all their GOPs by default.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Very easy. MPEG Sequence Maker can only put a sequence header before a GOP. It also has a tool to analyse where any existing sequence headers already are (so it doesn't do anything stupid). A simple check is all that's required. Stop guessing and LOOK.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>How do you figure that? Tell an encoder to put a chapter mark at frame 3076, it compiles a legal entry point at frame 3076. If you can't figure out the Presentation Time Stamp for that frame in order to actually make use of it, that's a problem with the authoring program and not the MPEG encoder. </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

For example, not all DVD rips go smoothly. It may not be possible to start encoding from FRAME 1.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>Most definitely. You can't get Panasonic to compile a chapter point without crashing, so you turn every GOP into a chapter point, and take the one that's closest to the place you intended it to be that you can guess the PTS for. What I don't understand is why you'd take a such a crude workaround, write a 'how-to' guide out of it, and haughtily suggest that people take heed of it anytime they have a question about chapter points, as you've done here.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Perhaps it is fair to say that I'm not the only person who as written about this before. In any case, you've completely ignored the fact that all other MPEG-1 encoders of quality (TMPGEnc, LSX, CCE) also put an MPEG Sequence header before each GOP. Perhaps you should get your head out of the clouds and realise that it is simple a method that WORKS. Furthermore, I note that YOU didn't suggest a solution to the original poster of this thread on how to FIX his PROBLEM.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>I mean, jeezus, Vitualis, can't you just fix your damned PC? </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Same, bug (the plug-in version), multiple computers. Your overwhelming presuming on this is showing again.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>No, you're quite right. They were utterly irrelevant. </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

As you are... Your statements are nothing more than educated guesses. Like your previous arguments before (remember VCD vs. SVCD?) you presume that your educated guesses somehow are more important that REALITY. You were unbelievably arguing about VCD vs. SVCD quality when you YOURSELF had never made a SVCD from a DVD rip.

A case and point is your statement that adding sequence headers before each GOP is a pure waste of bandwidth. Firstly, you've admitted that you've never even tried it and thus it is nothing more than an educated guess -- a WRONG one -- and yet you persist with this pointless debate. Adding the headers increases the bitrate (if at all) by a negligable amount. Furthermore, as I've pointed out, several other encoders already do this by default (LSX, TMPGEnc). Are they wasting bandwidth too?

A second case and point is your objection to closing GOPs with TMPGEnc. All your theory is good and well, but have you actually even tried it?? How can you argue about quality when you've never done it yourself? As long as the end result looks good, it is all that matters. I'm not making a non-compliant stream... if anything, I'm possibly putting even more stringent conditions than necessary.

Regards.

_________________
Michael Tam

<font size=-1>[ This Message was edited by: vitualis on 2001-11-08 10:27:31 ]</font>

Quote

8th Nov 2001 03:07 #19

vitualis

Member

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>
On 2001-11-07 23:32:34, KoalaBear wrote:
If Panasonic crashes when you try to compile a chapter mark, you might consider fixing your computer rather than writing a 'how-to' guide based on a kludge.

It's entirely possible to specify a chapter mark to the accuracy of a single frame. This is in fact what most people are trying to do. If you can help them achieve that goal that's great, but if you tell them that they can only get within a quarter second of any chapter mark (and only then if they make every GOP a potential entry point) you should at least make the disclaimer that while it may be an example of shamefully poor craftsmanship, it will certainly work for them in a pinch.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

We don't live in a perfect work and no solution is perfect. Anybody with experience will already KNOW how to put chaptermarks which are frame accurate and thus wouldn't have the problem for which the article is a solution for.

This isn't an article for those who know what they are doing. Why would they need a guide? This is a guide for those people WHO DON'T know what they are doing.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>Figuring out how to reference them by their Presentation Time Stamp (PTS) is not. </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Conversion to seconds is high school mathematics. It seems obvious by your previous woeful calculation attempt that you have certain deficiencies in this area, but please don't insult the general public.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>When you compile a "forced I-frame" in Panasonic you get a chapter mark. When you compile a chapter mark in CCE you get a chapter mark. If TMPGenc doesn't handle chaptering properly, why not use an MPEG encoder that does?</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Why don't YOU tell that to the thousands of people out there what use TMPGEnc. I'm not trying to force people to use one encoder or another. I'm just showing a way around a common problem. Saying that people are silly for getting themselves into that problem to begin with is a ridiculous position and not one I believe in.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>The problem isn't the workaround required to make TMPGenc do something it's apparently not designed to do, the problem is that you'd suggest this behavior is normal and good coding practice to boot.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Once again, educated guessing. YOU can believe in whatever you want. I live in the REAL world. I look for solutions to problems not whinging about how it doesn't fit into my conception of the world.

Once again, I ask what real, functional, matters to people problem do you have with my guide. Hmmm???

The Panasonic solution
1. It fixes the entrypoint problem with VCDImager or any other VCD authoring proggy that can use entrypoints if you didn't/couldn't put chapter points before hand (going backwards through time and re-encoding is NOT a solution)
2. Contrary to your erroneous guess, it does not increase the bitrate
3. It does not harm or effect playback in any other way
4. With the Philips DVD player FFW and REW is now possible

The TMPEnc solution
1. It fixes the entrypoint problem with VCDImager or any other VCD authoring proggy that can use entrypoints if you didn't/couldn't put chapter points before hand (going backwards through time and re-encoding is NOT a solution)
2. Contrary to your moaning about encoding efficiency, it does not decrease the video quality of the end result in any REAL perceptable way.
3. It does not harm or effect playback in any other way

Look beyond your own little patch of knowledge. These are real solutions to real and common problems that people have. I couldn't give a crap that YOU don't have this problem. If you don't have a problem, you don't need a solution. This is for those people how HAVE a problem and want a solution (e.g., the top two posters of this very thread).

I also don't really care how YOU think that things are SUPPOSED to work. I work with the programs that EXIST and accept the problems as they come.

Regards.

Michael Tam
w: Morsels of Evidence

Quote

8th Nov 2001 05:45 #20

vitualis

Member

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>
And I suggest you learn the critical thinking skills necessary to argue your way out of a wet paper bag.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

How very appropriate.

A good scientist experiments to investigate hypotheses. They are open minded and do not hold onto some core DOGMA and refuse to see the evidence as it is.

I have already suggested several experiments that anyone can do to verify what I've stated.
Get a Panasonic encoded stream. It will not have MPEG Sequence Headers bar the one at the beginning of the stream.

This WILL NOT work for entrypoint placement with any program.

Demultiplex and run the elemental video stream through MPEG Sequence Maker and remultiplex.

The increase in file size is approx 300Kb per 800MB of video.

The file will now work with most/all authoring programs for entrypoints.

This is verifiable and undeniable. There is already a theory/hypothesis why it works.

Now what are the unscientific/irrelevant statements made in this thread:
1. "waste of bitrate" -- obviously not, where is YOUR evidence Koalabear or was it just a "guess"?
2. "waste of resources"
(a) disc capacity? obviously not
(b) time? inserting headers in front of all GOPs takes less time than only inserting them in front of specific ones due to time required for user interaction (what do YOU mean by "waste of resources" exactly?)
3. "should have added chaptermarks while encoding" -- completely irrelevant as the answer was in response to the AUTHOR of the thread who had ALREADY encoded his MPEG.

If you don't believe me, that's okay. I've explained what I've done. You can verify it YOURSELF.

Second case
A TMPGEnc stream encoded with GOPs open

A entrypoint placement isn't possible in a desired location because of a lengthy unclosed GOP

Encode again with the ONLY difference being putting the setting of closed GOP

Entrypoint placement IS now possible within 1/4 second resolution (because encoder didn't set specific chapter marks)

Now, what have been some unscientific/irrelevant statements made:
1. "In the case of a constrained bitrate (i.e., VCD-compliant MPEG-1) this will almost certainly have a negative impact on picture quality." -- where is YOUR evidence?? As I've stated, MY personal tests have yielded LITTLE impact to quality with TMPGEnc which is the encoder in question. I welcome other testers.
2. "Vague anecdotes" -- where is YOUR evidence that they were vauge and anecedotal? Dismissing of evidence is really very unscientific.

And so on...

I have written everything that can be tested if anybody wishes it. If you have EVIDENCE that somthing I stated is incorrect, I welcome it. I do not welcome someone whinging about a method they have no experience of because it doesn't fit into their view of encoding perfection.

Regards.

Michael Tam
w: Morsels of Evidence

Quote

10th Nov 2001 06:14 #21

KoalaBear

Member

Tsk, tsk, tsk, Mr. Tam.

Lobbing gobs of crap against the fan in the hope that you might get something -- anything -- to stick. Either you're incapable of sustaining a friendly disagreement or I've grossly overestimated your maturity level. Possibly both.

"Conversion to seconds is high school Mathematics ...
1:06:37:18 (25 fps?) = 3997.72 seconds ... Perhaps you don't know
how to convert hh:mms:ff to seconds?"

Grade school mathematics, actually. Educational standards must vary on your side of the Pacific more than I suspected. Let's try another example:

Say we insert a chapter mark at frame 119796. VCDImager expects us to convert that frame number into an elapsed time value instead, which is tricky in North America because the answer literally depends on how you choose to count it.

NTSC recognizes several drop-frame and non drop-frame timecodes. Thus, a single frame number could have three different clock values depending on the timecode you're working with:

23.97fps = 0.0417188151 sec/frame
29.97fps = 0.0333667000 sec/frame
30.00fps = 0.0333333333 sec/frame

Frame number 119796 is therefore either 4997, 3997, or 3993 seconds from zero depending on the timecode, PLUS a fractional offset necessary to specify the frame's position to a resolution finer than one second. With me so far?

The integer portion is easy enough, but we can't solve for the fractional part without more information. The VCDImager documentation doesn't tell us how the PTS clock is calibrated, so we need to make an Educated Guess(tm). The PTS reference has six decimal places, so let's assume the clock ticks away in microseconds. In non drop-frame timecode (30fps) the target frame lies six frames past the integer part, so the PTS for frame 119796 would be 3997.000018 ((30 / 1,000,000) * 6).

Regardless of the reason PTS was chosen as VCDImager's method of entry point reference, it's a pain in the butt to work with.

"Once again, I ask what real, functional, matters to people
problem do you have with my guide. Hmmm???"

I don't have a problem with your guide, I just wanted to know the rationale behind your procedure. You've since explained that you don't know how to work with chapter points with an accuracy greater than half a second, and besides, the guide was targeted to people who know even less about the subject than you do. Those answers are good enough for me.

Q: Tell me how you arrived at the conclusion that ...
MPEG-1 encoders, close all their GOPs by default.

A: "MPEG Sequence Maker can only put a sequence header before
a GOP ... It also has a tool to analyse where any existing
sequence headers already are (so it doesn't do anything stupid)."

Q: You can't get Panasonic to compile a chapter point
.... so you turn every GOP into a chapter point

A: " ... MPEG-1 encoders of quality (TMPGEnc, LSX, CCE) also
put an MPEG Sequence header before each GOP."

Interesting. Your "proof" that all MPEG-1 encoders close their GOPs by default is that MPEG Sequence Maker can only put a sequence header before a GOP (duh). Later you say that any "encoder of quality" always inserts a sequence header before each GOP.

Apart from contradicting yourself (if the encoder put a sequence header before each GOP you wouldn't need MPEG sequence maker), neither of these statements constitutes any kind of "proof" that MPEG-1 encoders close all their GOPs by default.

You just made that up -- another 'little white(book) lie,' as it were.

Grow up already, Mr. Tam.

====================================

PS to HVR, if he's out there:

While there are several methods of entry point reference (PTS, SMPTE, frame number, etc.) all of these have cases in which the values are difficult or impossible to predict in advance. Consider an MPEG file encoded at 23.97fps that has RFF flags inserted to bring the frame rate up to 29.97fps. Relative to the encoder, the position of the target frame has changed, the timecode value has changed, and only VCDImager knows what the PTS will be.

But say that entry points were indexed according to their ordinal values instead. The true index, whether it's a PTS or whatever, would be known to the compiler so that a file containing six chapters could be referenced by the author as 'entry00' ... 'entry05'.

What do you think?

Quote

10th Nov 2001 09:42 #22

vitualis

Member

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>
On 2001-11-10 13:14:44, KoalaBear wrote:

Grade school mathematics, actually. Educational standards must vary on your side of the Pacific more than I suspected.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Rather interesting statement. I'm not the one with the difficulty calculating the times for entrypoints. I'm also not the one who made a rather ridiculous mistake in his calculations. Furthermore, did you even read the material in your own link: http://www.xenu.net/archive/baloney_detection.html

Ad hominem

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>Say we insert a chapter mark at frame 119796. VCDImager expects us to convert that frame number into an elapsed time value instead, which is tricky in North America because the answer literally depends on how you choose to count it. </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

No, it is not. It is quite simple. I think that you are looking at it from a much too complex angle. Working it out from a frame number is rudimentary. All that is required is knowledge of the framerate of the clip:

Frame number: 119796
23.976 fps: 119796 / 23.976 = 4996.496 s
29.97 fps: 119796 / 29.97 = 3997.197 s

Assuming that there really was a chapter mark on this frame, the entry will be frame accurate.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>You've since explained that you don't know how to work with chapter points with an accuracy greater than half a second, and besides, the guide was targeted to people who know even less about the subject than you do. Those answers are good enough for me.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Hmm... ad hominem again. Learn to read. I know exactly how to put chapter marks in specific frames and reference them as such. I am also aware of the limitations of some encoders. The guide wasn't even addressing this issue. Remember it was a reply to the ORIGINAL question -- a method of using chapter marks after the mpeg is encoded if chapter marks were not or could not be placed beforehand.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>Interesting. Your "proof" that all MPEG-1 encoders close their GOPs by default is that MPEG Sequence Maker can only put a sequence header before a GOP (duh).</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Incorrect. Obviously you've never used MPEG Sequence Maker so perhaps I should have written it more precisely. You can use it to find out where the GOP headers on the Panasonic MPEG encoded stream. A quick check reveals no open GOPs.

Furthermore, I did not say "all" mpeg encoders. Don't quote me out of context.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>Apart from contradicting yourself (if the encoder put a sequence header before each GOP you wouldn't need MPEG sequence maker), neither of these statements constitutes any kind of "proof" that MPEG-1 encoders close all their GOPs by default.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

As above. MPEG Sequence maker does more than just put in sequence headers which was what I was implying before though you obviously missed it. It can also analyse the stream to see where existing headers are and output the timecodes. I take offense to your allegation that I lied, especially as you obviously once again, didn't even bother checking the evidence.

1. MPEG Sequence Headers: they are put in front of each GOP by default by a number of MPEG encoders. Usually, these programs will have this as an option so you know before hand. You can use MPEG Sequence Maker to CHECK if you really want to.

2. Closed GOP in Panasonic and others: if sequence headers are not already present (e.g., Panasonic) you can use MPEG Sequence Maker to show the location of the GOP headers. Simiarly, if sequence headers are already present, you can list these. A quick survey will show whether GOPs are closed or not.

As for maturity, perhaps you should take a long hard look at yourself. In your last post, you've done nothing but take little bits of what I've written before and taken them out of context. I will presume for now that you simply didn't understand what I posted before rather than it being deliberate on your part.

As for your little personal attacks, they do nothing more than characterise you.

As I detailed before, you are the party guilty here of either making things up, guessing and pretending it a fact, or moving the debate to points which aren't even relevant. Do I need to write the list again?
1. "waste of bitrate"
2. "waste of resources"
3. "vague anecdotes"
and etc. As you seem to love trivialities, I've written in detail how I've reached the method used in the guide and some of the justification. If you aren't willing to even look at the evidence presented properly, then you don't have a right to comment.

As for your suggestion of entrypoint placement, unless I'm misunderstanding you, it is completely unworkable. The only time it would work is if the MPEG encoder ONLY inserted chapter marks at those times specified (where "entry01" etc., would make sense). As I've stated several times and you seem to have continually ignored, most of the commonly used MPEG encoders place sequence headers before each GOP (e.g., TMPGEnc) and you cannot turn this off (at least not with the template). Your suggested system would be even harder than frame number or absolute playback time as the ordinal number of possible entrypoint bears no relation to either the actual playtime or frame number.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>Consider an MPEG file encoded at 23.97fps that has RFF flags inserted to bring the frame rate up to 29.97fps. Relative to the encoder, the position of the target frame has changed, the timecode value has changed, and only VCDImager knows what the PTS will be.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Actually, I don't see your point. The absolute playtime of any particular part will remain the same. For example, if I wanted to place an entrypoint at exactly 120.52 seconds, it will be exactly 120.52 seconds with or without the flags. Similarly, if it were referenced by the absolute frame number (which what I would personally prefer), this hasn't changed either.

Regards.

_________________
Michael Tam

<font size=-1>[ This Message was edited by: vitualis on 2001-11-10 16:49:23 ]</font>

Quote

10th Nov 2001 10:52 #23

KoalaBear

Member

"I'm not the one with the difficulty calculating the times for entrypoints."

No, your the one who can't hit an entry point with an accuracy better than half a second.

"I think that you are looking at it from a much too complex angle."

I think the scope of the discussion was beyond your comprehension.

"... so perhaps I should have written it more precisely."

Perhaps you should have known what you were talking about before riding the "reply with comment" button like a bad driver rides the clutch.

"I take offense to your allegation that I lied."

I take offense that you did.

"As for your suggestion of entrypoint placement, unless I'm
misunderstanding you, it is completely unworkable."

You're completely misunderstanding me, but then I wasn't talking to you.

"For example, if I wanted to place an entrypoint at exactly 120.52 seconds,
it will be exactly 120.52 seconds with or without the flags."

No wonder you can't hit an entry point with an accuracy better than half a second.

Quote

10th Nov 2001 16:41 #24

vitualis

Member

Perhaps you should stop and think for a while... What you just posted doesn't even make much sense. Since you've suddenly taken a dislike to the "quote" function, I'll use bold as you did.

No, your the one who can't hit an entry point with an accuracy better than half a second.

Hmmm, I suppose that all the VCDs I've made with frame accurate entrypoints would discredit that presumption.

I think the scope of the discussion was beyond your comprehension.

Perhaps it was... but I somehow doubt it. I'm completely perplexed as to why you are treating the integer and fractional time seperately when you don't have to. This may explain why you need "burn/tweak cycles" to get your entrypoints right... As I've stated, I get frame accurate entrypoints anytime I want. Working out the absolute playtime is also rather simplistic if you know the frame number and framerate, and I've done so for PAL, NTSC and NTSC-FILM many times.

frame number = playtime * framerate

Perhaps you should have known what you were talking about before riding the "reply with comment" button like a bad driver rides the clutch.

I knew exactly what I was writing about since I've done it several times. In retrospect I suppose that it was optimistic of me to expect you'll even bother to read the post properly, let alone actually get the program to look what I was talking about.

No wonder you can't hit an entry point with an accuracy better than half a second.

I suppose that I can only repeat myself so many times. I can reference any entrypoint accurate to the frame if the chapter mark is there. You are the one who admitted to needing "burn/tweak" cycles which I find strange since nobody else I know who uses VCDImager needs to.

As for "not talking to me" this is a public forum. Anyone can reply to anybody they wish. If I'm misunderstanding you, I would be interested in exactly how. My understanding of your description is that it is not a practical system for the common MPEG encoders. Since you disagree, please enlighten us all.

BTW, for someone talking about civility and maturity, you really need to read what you linked before: http://www.xenu.net/archive/baloney_detection.html
Ad hominem

Regards.

_________________
Michael Tam

<font size=-1>[ This Message was edited by: vitualis on 2001-11-10 23:44:22 ]</font>

Quote

12th Nov 2001 09:02 #25

KoalaBear

Member

"Since you've suddenly taken a dislike to the "quote" function, I'll use bold as you did."

My dislike of quoting is hardly sudden. I think they're a waste of bandwidth, make discussions more difficult to read, encourage poor thinking and writing habits, and act as a crutch for people lacking general ideas to focus on petty specifics. I'd be happy to dispense with them altogether, but if that's not possible perhaps I can make them easier to read.

"In retrospect I suppose that it was optimistic of me to expect you'll even bother to read the post properly ... I suppose that I can only repeat myself so many times."

MPEG-1 encoders do not create a stream of closed GOPs by default. Even if you found one that actually does, no chain of logic can ever be constructed to prove that this is the rule and not the exception.

The premise is false, Michael.

You can't pass GO. You can't collect $200. The game was forfeit on square one. Give it a rest already.

"As for "not talking to me" this is a public forum. Anyone can reply to anybody they wish."

Perhaps, but that doesn't obligate me to answer you, does it?

"If I'm misunderstanding you, I would be interested in exactly how."

I hang out here because I enjoy explaining difficult ideas. I don't know how much MPEG literature you've actually read, but there aren't many good books on the subject and much of what can be found on the web assumes you have a postgraduate reading level. So if somebody wants to know what motion compensation is, for example, or what quantization tables are about, you need to have some Theory(tm) under your belt in order to understand these concepts yourself let alone explain them clearly to others.

The upshot of that understanding is that it's easy to tell the difference between shit and shinola. If you have a good theoretical understanding of MPEG, you don't need to consult any references in order to know that fixed length GOPs are not a requirement of White Book, or that closed GOPs every other second are not a requirement of VCD 2.0.

You see, [S]VCD is based on the MPEG specification, not the other way around. NV Philips can impose constraints on the parameters of an MPEG file (i.e., resolution and bitrate) in order to establish VCD compliance, but it cannot impose restrictions on the syntax of the MPEG bitstream itself.

Your misunderstanding, I believe, is based on the presumption that if you name a document nobody has access to as your 'source,' nobody will ever discover that you told a 'little white(book) lie' for the purpose of turning the table on your opponent in an argument.

Does that clear things up for you a bit?

Quote

12th Nov 2001 15:32 #26

nsdn

Member

First of all ...Chill out dudes...

It is great to see a shoot out between two clearly intelligent people, it is a shame when both of u lower yourselves to hurling personal insults at each other.

I have seen Michael help a great many people in this forum and followed his advice myself quite a few times. And his points are valid, the original question has been answered effectively enough for the poster to satisfied.

One thing that Michael says is completely correct.

Results ARE more important than technicalities. It is how whatchable the result is, not how technically prefect it is. (being an engineer myself, I am prone to this also). MPEG is far from perfect, and if my chapter entry point is .5 of a second out I could not give a rats arse. Although I had noticed it and was curious to read this thread to understand why.

Perhaps you could start a new topic, chapter entry points debate, laced with malice.

BTW I drive my wife nutso tweeking stuff that she can’t even see…hehe

And now ur arguing about using quotes?…..get a grip lads….I am sure there are countless other questions that people are asking that you could doubtlessly both provide superior answers to rather than diving on here and checking to see if u can prove each other wrong another time around.

Quote

12th Nov 2001 16:00 #27

vitualis

Member

MPEG-1 encoders do not create a stream of closed GOPs by default. Even if you found one that actually does, no chain of logic can ever be constructed to prove that this is the rule and not the exception.

This is completely irrelevant. I never said that closed GOPs was the rule and I thus I have never tried to prove it. Stop taking me out of context.

I said that the Panasonic MPEG Encoder had closed GOPs that can be shown by CHECKING rather than GUESSING.

You've ASSUMED that closing GOPs would reduce the efficiency of MPEG encoding and if you've read my posts previously, I agree that this would be the case in theory. I'm, however, interested in the REAL impact on this in terms of the the commonly available encoders rather than just the hypothetical case. Closing the GOPs with TMPGEnc fixes a common authoring problem AND that tests would seem to indicate that there is little if any loss of quality.

If you disagree with that statement, do some encoding tests to SHOW otherwise, rather than badgering on about a theorectical point I don't even disagree with.

After searching through the internet, I can't find the reference to a closed GOP every 2 seconds so I concede that I'm probably mistaken. Rather it was an I-frame at least every 2 seconds which would make sense.

Perhaps, but that doesn't obligate me to answer you, does it?

What's the point of bringing up an issue of discussion if you then won't discuss it? I say that your suggested method of entrypoint definition as I understand it is absolute nonsense. If I'm wrong, then refute it.

I hang out here because I enjoy explaining difficult ideas.

That's fine with me. I would rather like to know why you were converting frames to seconds in that rather convoluted manner. Not only is it difficult, your answer wasn't even correct if you wanted to use that figure for authoring the XML with VCDImager.

I come to the forums to learn about topics pertaining to VCDs has well and I enjoy a good discussion. I do not respect, however, people who pretend that their theoretical knowledge compensates for their lack of experience. I also do not respect people who resort to petty name calling and personal attacks.

I have no doubt that you have a lot of knowledge regarding MPEG itself and you've proved that many times. However, you have also proved on the forums many times that you have very little practical knowledge in regards to making VCDs and SVCDs. For example:
Closed GOPs vs Open GOPs: theory aside, I've shown that with TMPGEnc there is little loss of quality along with the other benefits. There are simply practical reasons to have them closed. If you can't accept this, you are being blind to the obvious. So far, you have made no valid points against closing the GOPs in TMPGEnc that has a functional basis.

Sequence headers before each GOP: you first stated that it would be a "waste of bandwidth" and then rather cryptically a "waste of resources". I have refuted both. Once again, you have made no valid points against my method with respect to a solution to the top two posters problem.

Frame accurate entrypoints: despite your persistent and somewhat spiteful allegations that I can't define entrypoints accurate to the frame, it should be obvious to anyone reading this thread that I can and have done so many times. It is somewhat ironic that you are making this charge when you yourself admitted that you can't get frame accurate entrypoints (burn/tweak cycles) and then proved it by your calculations.

Other examples: and the list goes on. This behaviour of yours is evident in other threads as well, most notibly the VCD vs SVCD thread.

Knowing a lot of theory does not mean that you know a lot about VCD. Before you start arguing about practical methods and considerations, make sure you understand the issues first.

Regards.

_________________
Michael Tam

<font size=-1>[ This Message was edited by: vitualis on 2001-11-12 23:01:38 ]</font>

Quote

12th Nov 2001 16:26 #28

vitualis

Member

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>
On 2001-11-12 22:32:14, nsdn wrote:
First of all ...Chill out dudes...</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Absolutely. (hope you don't have a problem with quotations)

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>Results ARE more important than technicalities. It is how whatchable the result is, not how technically prefect it is. (being an engineer myself, I am prone to this also). MPEG is far from perfect, and if my chapter entry point is .5 of a second out I could not give a rats arse. Although I had noticed it and was curious to read this thread to understand why.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

A voice of reason at last!

Actually, you can get frame accurate entrypoints, but you will have had to have known and set BEFORE you encoded the MPEG the frames you wanted for chapters. Panasonic, TMPGEnc and CCE (?stand-alone only -- can't remember) have this functionality. In TMPGEnc (12a), it is under MPEG Configuration --> GOP structure --> Forced frame type --> Configure.

I have never gotten the Panasonic plug-in with FlaskMPEG to work.

As stated before, there are some problems with "frame accuracy" and DVD ripping. How frame accurate DVD2AVI and FlaskMPEG are with respect to the original frames on the DVD is somewhat questionable. The problem is, of course, you don't really know until AFTER you've finished encoding the MPEG. The newest versions of both the above are probably OK (i.e., if not frame accurate, it is close enough). Flask 0.5x series is hopeless as it is always off by 8 frames.

To get the frame numbers of the "chapters" in the original DVD, you can use a tool like "ChapterXtractor" on the relevant IFO file. Smartripper on movie mode (I think) also creates a text file with the relevant frame numbers. What is required is for you to enter the numbers into the encoder before you hit the start button.

To be perfectly honest, I don't usually bother for DVD rips, mainly because I prefer Panasonic to TMPGEnc. Furthermore, the accuracy of not entering the chapter points beforehand is less than 1/4 of a second rather than 1/2. In my experience, this makes no functional difference to the end result (VCD playback on TV) at all.

I usually only design a VCD with frame accurate chapter entries for home videos where the care factor is higher.

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>Perhaps you could start a new topic, chapter entry points debate, laced with malice.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Point well taken. This is all getting rather idiotic.

Regards.

Michael Tam
w: Morsels of Evidence

Quote

13th Nov 2001 09:47 #29

KoalaBear

Member

NSDN: Yes, I got the answer to my questions a long time ago. The discussion was purely for sport after that. The Internet is one of the few places (hell, it's the only place) you can watch two clearly intelligent people on opposite sides of the planet match wits in such a gladiatorial fashion. Like American football it can be a tedious game, but every now and then somebody scores an exhilarating touchdown. Unlike American football, however, there's no referee, no time limit and no television commercials.

To extend the analogy a bit, all that's required to end the game is to accept the score as it is and decline to play another round; but like a compulsive gambler he won't relent until he loses his last dime. If you don't believe me, just watch. He'll never stop posting even after nothing has been left unsaid.

As for starting a new thread, well, two wrongs don't make a right. If the discussion is perceived as malicious (and it's aggressive in my opinion, but not particularly hateful) then it's probably a good idea to keep it restricted to one place.

Mr. Tam: Must I take you out to the woodshed again?

"I never said that closed GOPs was the rule and I thus I have never tried to prove it. Stop taking me out of context."

11/07 -- "It should be noted that several other encoders encode MPEG-1 for VCD with closed GOPs by default (Panasonic, LSX and ?Xing)."

11/10 -- "2. Closed GOP in Panasonic and others: if sequence headers are not already present (e.g., Panasonic) you can use MPEG Sequence Maker to show the location of the GOP headers."

In what context should I take these statements, then? That if you repeat an error often enough it will eventually mutate into fact? The premise is false, therefore the conclusion is false, no matter what kind of "proof" you provide to show otherwise.

"I said that the Panasonic MPEG Encoder had closed GOPs that can be shown by CHECKING rather than GUESSING."

Checking what? A GOP header is not a closed GOP. A GOP header does not indicate the presence of a closed GOP. If I run MPEG Sequence Maker and it tells me every GOP is preceded by a GOP header, how does that 'show' that the GOPs created by Panasonic are closed? It does not. It cannot, because you cannot violate causality.

You must think harder, Michael. It is not easy to prove that the sky is green.

"What's the point of bringing up an issue of discussion if you then won't discuss it?"

I didn't say I wouldn't discuss it, I said I wasn't talking to you. You understand the difference.

"I also do not respect people who resort to petty name calling and personal attacks."

I have never called you a name. That's just not my style. And I needn't resort to personal attacks because I'm nowhere close to running out of ideas.

"despite ... allegations that I can't define entrypoints accurate to the frame, it should be obvious to anyone reading this thread that I can and have done so many times."

No, the only thing that's obvious to anyone reading this thread is that you're confused about the difference between opinion and fact.

Quote

13th Nov 2001 12:37 #30

vitualis

Member

There is probably little more to discuss but I think we can agree that we don't see eye to eye on this. I've enjoyed this little debate.

In any case, the method stands, it works, and it is described in the link in my first post. If there are problems that you find with it, send me an e-mail. I'll be leaving in a few days to do an elective term in Alice Springs for two months and will be far away from any net access so don't be surprised if I don't reply for a while.

On a totally separate issue, I'm curious as to why you chose the nick "KoalaBear". Is there an Aussie connection?

Regards.

_________________
Michael Tam

<font size=-1>[ This Message was edited by: vitualis on 2001-11-14 00:42:02 ]</font>

Quote

TSCV Entry Point Error??

Thread Tools

Similar Threads

DVD Maestro Entry Point Not Found Error

r6002 floating point error with MPC , maybe

MPC Runtime Error, 6002 floating point support not loaded.

Point to point sharing with wifi adapter and wifi router?