Seamless flag should be what ? when replacing cell.

[jinjin_jp]

I exprienced strange thing.
I've been thought it is better STC discontinuity and non-semamless when replacing cell.
But because replaying freezes on portable DVD player, I tried to change non-seamless to seamless, so freezing was fixed.
Is is understandable?

Details of procedure is;
(1)Capturing music TV program on PC.
(2)Authoring to DVD-Video by Movie Writer (it is bungled software of PC).
(3)Editing by DVDShrink Re-Author mode. There is each song which is cutted to needed part as 1 VTS.
*There are many VTSs so felt pause when up to next song. So I usually make it to 1 VTS cosists of many chapters like below.
(4)Preparing DVD Video of one(first) song by DVDShrink.
(5)Create new cell by PgcEdit.
(6)Replace cell; VTS * of (3) to celll * by VobBlanker.
Then replaced cell is STC discontinuity and non-semamless, and I think it is better.
But this time it has problem of freezing on several point, and it is fixed by change non-seamless to seamless by PgcEdit.

Regards.

[r0lZ]

Strange. IMO, the opposite could fail (a seamless cell at the LB position, for example), but a cell can theoretically always been forced as non-seamless.

I had a similar problem in the past when I used IfoEdit's Join Clips function. My Sony player did not like the transitions between the cells. At that time, I didn't know the usage of those mysterious cell flags, and I was too scared to change them, so I've never used IfoEdit to join clips any more. Currently, I use Womble MPEG Video Wizard DVD (unfortunately not free) and I have never had problems. (But most modern players are much more tolerant than my old Sony.)

[jinjin_jp]

Thanks for the res.

I truely feel strange.

Before above suceeded method, I tryed several other method,
1)add cell commands which jump to next cell.
2)add tiny blank cell after each cell.
3)create and replace cell by DvdReMakePro instead of PgcEdit and VobBlanker. (Then new cells are seamless at first, so I edited to non-seamless.)
but all failed.

I think it refers to feature of cell and DVD player.
Because,
*There is cells which don't freeze and cells which freeze (but not always).
*Even when freezing once, after chapter up/down it can replay without freeze there.
*There is difference of possibility of freezing among DVD player.
I have 3 DVD players. This time I tryed BLUEDOT portable player, because it is most easily freezing.

Anyway, I think it had better to change my thought that non-seamless is always more safe when editting.

Regards.

[r0lZ]

Anyway, I think it had better to change my thought that non-seamless is always more safe when editting.Yes, it's the (strange) conclusion of your experience.
Thanks for sharing it with us.

[jinjin_jp]

As one of possibility, I suspect first GOP of the cell is closed or open. (and depend on DVD player)
In this case, there are 25 cells except for first cell, and 11 cells are open GOP and 14 cells are closed GOP.
There are several(about 4 or 5, each frequency is different) freezing point, and their first GOP of next cell are all open GOP.
It is not easy to think that it is a coincidence ?

Regards.

[r0lZ]

Maybe you're right. It makes sense to close the GOP when a new cell begins. However, I don't think it's mandatory.

[blutach]

I'd do a full demux and remux. That way, I know things are right.

Regards

[jinjin_jp]

I'd do a full demux and remux. That way, I know things are right.

Regards

I've had the problem again.
This time it can't be resolved by changing seamless flag. I made 5 coasters.
So I tryed to demux by PgcDemux and remux by Muxman about problematic cells.
Then the problem was resolved.
Thanks very much for the suggestion.

By the way, may I have a question ?
There were 2 problematioc cells in all 19 cells.
I confirmed audio delay by PgcDemux and input it by Muxman.
After that, when confirmed remuxed file, each audio delay was changed, and file's size was decreased.
(1)audio delay : -100msec => - 4msec , and file's size : 244,306KB => 244,304KB
(1)audio delay : -108msec => -12msec , and file's size : 221,988KB => 221,986KB
Both were audio delay changes +96msec, and file's size changes -2KB.
Does it mean something ?

Regards.

[blutach]

No, it's just muxman doing its thing and making the delays as little as possible. I've had audio delays of say -200ms (meaning the audio starts earlier than the video) that after remux turn out to be near zero. I hadn't thought about it but I guess in these circumstances, file size might be altered, too as a packet is dropped.

mpucoder can explain more, I am sure.

Regards

[jinjin_jp]

No, it's just muxman doing its thing and making the delays as little as possible. I've had audio delays of say -200ms (meaning the audio starts earlier than the video) that after remux turn out to be near zero. I hadn't thought about it but I guess in these circumstances, file size might be altered, too as a packet is dropped.

I confirmed more.
I demuxed the remuxed file and compare demuxed file's size and log of PgcDemux between before and after remux.

size of Video file --- not change
(1)226,192 => 226,192 KB, (2)205,549 => 205,549 KB
Number of Video Packs --- not change
(1)114,859 => 114,859, (2)104,382 => 2104,382
size of Audio file --- decrease
(1)12,576 => 12,573 KB, (2)11,400 => 11,397 KB
Number of Audio Packs --- decrease
(1)6,375 => 6,374, (2)5,779 => 5,778
Number of Nav Packs --- not change
(1)919 => 919, (2)833 => 833

It seems to be what you say.(I guess in these circumstances, file size might be altered, too a packet is dropped.)

But I can't understand why the problem is resolved.

Regards.

[blutach]

But I can't understand why the problem is resolved.
This is what5 the remux does - it muxes things properly, making sure the timings and pointers are perfect.

Regards

[jinjin_jp]

This is what5 the remux does - it muxes things properly, making sure the timings and pointers are perfect.

Regards

Thanks for the explanation.

I looked at VOB by VobEdit.
I noticed to be rewriten the first Audio Pack of the cell by remuxing. Second and later cells seem to be same as before remuxed.
Otherwise when trimming by DVDShrink, all Audio Packs seem to be same.

***** the first Audio Pack of the cell by remuxing *****
[Pack Header]
[0000] Pack identifier (start code) 442 [000001ba]
[0004] SCR (System clock reference) 68 0 6 100 148 173 [44 00 06 64 94 ad ]
SCR 00019602.086
[000a] Program Mux Rate: 25200 (1260000 BPS) (10080000 bps) 1 137 195 [01 89 c3 ]
[000d] Pack stuffing length: 0 248 [f8]

[Audio MPEG Stream]
[000e] Audio Stream start code 448 [000001c0]
[0012] Length 2028 [07ec]
[0014] PES Header data content flags 33153 [8181]
PES scrambling control: 0
PES priority: 0
data alignment indicator: 0
copyright: 0
original or copy: 1
PTS exist?: 1
DTS exist?: 0
ESCR flag? 0
ES rate flag: 0
DSM trick mode flag: 0
additional copy info flag: 0
PES CRC flag: 0
PES extension flag: 1
[0016] PES HeaderData length 8 [08]
[0017] PES HeaderData 33 0 1 194 131 30 64 32 [21 00 01 c2 83 1e 40 20 ]
header data details:
PTS 00024897
PES private data flag: 0
pack header field flag: 0
program packet sequence counter flag: 0
P-STD buffer flag: 1
PES externsion flag 2: 0
[001d] P-STD buffer 16416 [4020]
P-STD buffer scale: 128 bytes
P-STD buffer size: 32 (=4096 bytes)

[001f] Audio-MPEG Frame

***** the second Audio Pack of the cell by remuxing *****
[Pack Header]
[0000] Pack identifier (start code) 442 [000001ba]
[0004] SCR (System clock reference) 68 0 6 187 109 175 [44 00 06 bb 6d af ]
SCR 00022381.215
[000a] Program Mux Rate: 25200 (1260000 BPS) (10080000 bps) 1 137 195 [01 89 c3 ]
[000d] Pack stuffing length: 0 248 [f8]

[Audio MPEG Stream]
[000e] Audio Stream start code 448 [000001c0]
[0012] Length 2028 [07ec]
[0014] PES Header data content flags 33152 [8180]
PES scrambling control: 0
PES priority: 0
data alignment indicator: 0
copyright: 0
original or copy: 1
PTS exist?: 1
DTS exist?: 0
ESCR flag? 0
ES rate flag: 0
DSM trick mode flag: 0
additional copy info flag: 0
PES CRC flag: 0
PES extension flag: 0
[0016] PES HeaderData length 5 [05]
[0017] PES HeaderData 33 0 3 6 3 [21 00 03 06 03 ]
header data details:
PTS 00033537

[001c] Audio-MPEG Frame

Regards.

[mpucoder]

Yes, when muxing with negative audio delays MuxMan removes packets (AC3 packets are 32ms in duration). These packets actually belong to the previous cell, so removing them does no harm. This also prevents audio from being heard for any significant amount of time prior to the first image and provides more bits for preloading the video buffer.

The first pack in a VOB of each stream, be it audio, video, or subpicture, must have a PES extension to declare the buffer size used as the target for multiplexing.

[jinjin_jp]

@mupcoder

Thanks very much for the explanation.
I understand Muxman's feature and the reason why it is better to remux.(When trimming by DVDShrink, the first pack in VOB dosn't have a PES extention in my case.)

Regards.

[blutach]

Shrink and other transcoders/cutters will just cut out the first little bit and will not set PES or reset the PTS and STC.

Regards