[RESOLVED] Adding Support for Japanese ISDB-T SD to HD Program Switching Detection

[mikeyakame]

I've cut out a sample from one of my recordings for you which hopefully should be enough to work with.

Basically what some stations in Japan do (as per ISDB-T spec) is broadcast using 2 SD channels (4 segments each) with unique programming airing on each at the same time, and then for certain programmes they will switchover to a single channel 8 segment HD broadcast which shares the network id with the first SD channel. So basically its a seamless switch right at the start of the first time slot wherein a HD programme airs, and then a seamless switch back to 2 SD channels at the end of the HD block.

The end switch isn't really an issue since it doesn't tend to interfere with much programming. Japanese programming typically starts within 20-30 seconds of the programming slot, sometimes not even that so when recording based off the EPG one plays it safe by starting the recording 30 seconds or so prior to the slots time. The switch itself is just a PMT version update where the video PID for the main programme is changed from one PMT update to the next. In this sample the PMT at offset 0x008F9AD0 is the version update where the video PID is remapped from 0x0121 to 0x0111 (SD->HD).

Without manually setting the Video PID DGIndex gets to the end of the SD segment before getting stuck at the resolution switch. If i manually set the video pid to 0x111 at this point, then i'm able to index the transport stream and have the resolution detected correctly as 1440x1080 and not 720x480.

The actual switchover occurs at ~106k packets or so into the recording, so its roughly around the 29 second mark. Would it be possible to add some PMT update detection at the start (say first 2-300k packets?) of a transport stream for this kind of scenario (rare as it probably is). Discarding the SD content is perfectly valid since it's useless, and just correcting the video upon detecting a seamless video switch would be more than adequate.

You can grab the sample from here:
http://ar.ziroh.be/sample_isdb-t_merge_ ... oadcast.ts

Hopefully it's not too much of a bother! Thanks.

[admin]

If you are asking me to handle dynamic resolution changes, I can tell you that is not going to happen. You'll have to cut the different pieces manually.

[mikeyakame]

Alright. In that case where would you consider a decode compliant boundary to cut the stream at? Do I need to keep at least 1 one PAT/PMT/PCR/Audio sequence before the first video packet after the change? Just so I know how much to remove so DGIndex has no problem reading the cut file after. Would I be safe to assume if I output from the first PAT packet right before the PMT sequence with the updated video PID that it should be compliant?

[admin]

Yes, that strategy sounds fine to me.

[BarryW]

With TS Packet Editor you can switch the SD stream off and create a TS file containing just the HD video and audio streams.
Use DGIndexNV on this modified TS file to create the DGI, AAC and AVS files.
When the AVS is viewed in AvsPmod frame 0 and 1 contain upscaled images from the SD stream.
Adding Trim(2,x) at the end of the AVS file will remove these frames.
DGIndexNV seems to start creating the audio AAC stream at the point where the HD video starts which is about 14 seconds into the file.
The audio will probably need correcting in Audacity to remove the 2 video frame times at the start to keep the lip sync correct and also remove any excess audio from the end after the x trim position.