GBPVRConvert problem -show name length?

[bgowland]

There is a short series of programmes currently showing on BBC4 (Freeview). The programme runs from 19:00 - 20:00 and I can see from the log that the auto-convert starts just after the post padding (20:06) but it's still running when I get home from work at gone midnight and the mpg file is a fraction of the size of what it should be.

I think other conversions are OK as "Doctor Who Confidential" transcoded fine on Saturday. I haven't tweaked anything that I'm aware of (too busy working shifts to even think about it).

Could it be the length of the programme name? The log shows the name truncated for the SBSource and GB-PVR Writer filters or is this a logging issue rather than a restriction in DS filters?

I can't think of anything odd about these recordings other than that.

Cheers,
Brian (log attached - GBPVRConvert still running at 1am)

[sub]

Yeah, I see what you mean about the file name length in the logs. I'm not really sure. It might be worth trying a couple of many tests (try original file name and command line again to confirm still a problem, then move/rename to shorter path and try again).

[bgowland]

I've currently got a 'hung' graph in GraphEdit built using those three filters. The process is at 90% CPU usage and the mpg file is at 846KB and stuck.

There shouldn't be anything special about BBC4 programmes that I can think of.

I'll try shortening filenames with GrpahEdit - if that works I'll try GBPVRConvert again.

Cheers,
Brian

[bgowland]

Hmmm...

BBC Four is one of the channels which switches in when another channel (CBeebies) stops broadcasting. The problem recordings are right at the start of BBC Four's time-slot (7pm). Viewing one of the dvr-ms files with WMP11, I see 33 seconds of CBeebies closing down (the 'counter' in WMP stops at exactly 00:33) - if I drag the WMP progress bar a few minutes on, BBC Four has started broadcasting and the audio plays back fine but the video goes in 'fast-forward'.

BBC Four is currently showing a video ES bitrate of 15 Mbps and I can pretty much guarantee that they don't push CBeebies out at that bitrate.

This is pretty nasty - it suggests that the problem is caused by a video ES bitrate switch at the beginning of the recording (CBeebies and BBC Four share the same AV ES PIDs even though the PMT PIDs are different).

If that's the case then it will affect any BBC Four recording that starts at 7pm if I use pre-padding. :eek:

I'll adjust the pre-padding for tomorrow's recording and see what happens.

Cheers,
Brian

[bgowland]

I adjusted the recording for tonight's programme to have 0 mins pre-padding. This is from the convert log...

Code:

2007-05-23 20:05:29.552    INFO    Graph contains the following filters:
2007-05-23 20:05:29.552    INFO     - D:\GB-PVR\The Edwardians in Colour The Wonderful World of Albert Kahn\The Edwardians in Colour The Wonderful World of Albert Ka
2007-05-23 20:05:29.552    INFO     - CyberLink MPEG Muxer
2007-05-23 20:05:29.552    INFO     - D:\GB-PVR\The Edwardians in Colour The Wonderful World of Albert Kahn\The Edwardians in Colour The Wonderful World of Albert Ka
2007-05-23 20:05:29.630    VERBOSE    About to start graph
2007-05-23 20:05:29.630    VERBOSE    transcode processing started
2007-05-23 20:06:44.552    VERBOSE    Received EC_COMPLETE
2007-05-23 20:06:44.552    VERBOSE    transcode processing complete

Me and the wife are going to have to remember to remove pre-padding from any recording on BBC Four if it starts on the changeover from CBeebies. Bah!

There's not much you could adjust in GB-PVR to avoid this, sub, except build in a special '7pm BBC Four' test which I'm guessing ain't likely to happen.

Cheers,
Brian

[sub]

You could maybe do a full transport stream recording for the few minutes over this period and I'll try running it up in the debugger. I'm sure if I can see it happening then I'll be able to come up with some work around.

Do you happen to know if the Cbeebies and BBC Four share any PIDs? I can see things getting confused if its receiving data (like on an audio PID on Cbeebies), then it starts transmitting data using an entirely different timestamps for BBC Four.

[bgowland]

You could maybe do a full transport stream recording for the few minutes over this period and I'll try running it up in the debugger. I'm sure if I can see it happening then I'll be able to come up with some work around.

I'm normally working at 7pm but I've got a night off tonight so I was going to investigate further anyway. It's likely to be about 125 MB/min - if you still have the DVDs with the TS captures I sent over some time back, I did some which I deliberately timed for the CBBC/BBC Three and CBeebies/BBC Four changeovers - perhaps they could be of use. I'll do a capture anyway.

Do you happen to know if the Cbeebies and BBC Four share any PIDs?

From my post yesterday...

BBC Four is currently showing a video ES bitrate of 15 Mbps and I can pretty much guarantee that they don't push CBeebies out at that bitrate.

... it suggests that the problem is caused by a video ES bitrate switch at the beginning of the recording (CBeebies and BBC Four share the same AV ES PIDs...

The PCR_PID of the PMTs for UK Freeview seems consistently to be the video ES PID (from what I've seen). I'm guessing the bitrate doesn't change on the audio between CBeebies and BBC Four but I suspect the video bitrate does. When you lock the profile for the SBSink, doesn't that lock the timing info based on what the SBSink is receiving at the time? If that's the case then wouldn't you need to monitor the streams for bitrate change then unlock/re-lock the SBSink profile 'on the fly'? Urrk!

Cheers,
Brian

[sub]

I'm normally working at 7pm but I've got a night off tonight so I was going to investigate further anyway. It's likely to be about 125 MB/min - if you still have the DVDs with the TS captures I sent over some time back, I did some which I deliberately timed for the CBBC/BBC Three and CBeebies/BBC Four changeovers - perhaps they could be of use. I'll do a capture anyway.

Yeah, I do still have them, so I'll take a look in a few days (want get the pre-release out first).

When you lock the profile for the SBSink, doesn't that lock the timing info based on what the SBSink is receiving at the time? If that's the case then wouldn't you need to monitor the streams for bitrate change then unlock/re-lock the SBSink profile 'on the fly'? Urrk!

The Microsoft Video Analyzer filter which sits infront of the sync is supposed to monitor and be able to cope with these types of changes.

[bgowland]

Yeah, I do still have them, so I'll take a look in a few days (want get the pre-release out first).

No problem. I'll do a capture anyway just in case there's anything new in the way BBC Four is broadcasting. I'll also adjust any pre-padding for upcoming recordings.

The Microsoft Video Analyzer filter which sits infront of the sync is supposed to monitor and be able to cope with these types of changes.

I'll take your word for it . I've read the MSDN docs on that filter several times over and I still haven't worked out what it does. :confused:

Cheers,
Brian

[sub]

Does BBC Four and Cbeebies have different service_ids? If so, then I have a theory you might be able to fix it by setting:

<BDAUsePsiParser>true</BDAUsePsiParser
<BDAAutoMapPids>true</BDAAutoMapPids>

and by editting the database to set the PIDs for these channel some invalid PID. This way the audio/video pins on the demultiplexer wont supply any data until the PsiParser sees the BBC Four service transmitting and automatically maps the correct PIDs for BBC Four. I'm not sure if the DVR-MS mux would time out waiting for data though.

Sorry...technical I know...