But this is not just an x264 problem--the error occurs with interlaced MPEG2 as well.

I wonder if the new 5.2 version includes a fixed tswrapper.dll? Can someone with access to both 5.0 and 5.2 look and compare? EDIT: I see the OP has both--never mind then; it's broke.

AFAIK absolutely the only x264 param that DVDAP doesn't like is bpyramid; you have to change that from strict to none.

Thank you, musicvid & BlackMax ! Fortunately here at my system b-pyramid strict has been accepted by DVD-A 5.0 and 5.2 on progressive AVC streams.
An example of a accepted 1280x720x50p commandline (although for recent versions of x264 some of the parameters are now redundant):

"D:\x264\x264_x86_r1947_unpatched.exe" --preset slower --tune film --crf 18.0 --level 4.1 --bframes 3 --ref 6 --slices 4 --pic-struct --sps-id 1 --aud --force-cfr --b-pyramid strict --open-gop --keyint 25 --min-keyint 2 --vbv-bufsize 24000 --vbv-maxrate 27500 --deblock -1:-1 --qpmin 10 --qpmax 48 --qpstep 4 --ipratio 1.2 --pbratio 1.1 --aq-mode 1 --weightp 0 --me umh --merange 32 --mvrange 511 --subme 10 --trellis 2 --psy-rd 1.0:0.15 --videoformat pal --sar 1:1 --bluray-compat --colorprim bt470bg --transfer bt470bg --colormatrix bt470bg --output D:\Werbung5.264 --demuxer avs "E:\! All-in-All 20.avs"

I repeated a 1920x1080x25i encode with the recent x264 r1995 (MBAFF patch committed), same rejection by DVD-A as before.
Will continue testing with interlaced HD-MPEG-2 from HCEnc.

Edit: Test finished. Interlaced encodes from HCEnc 0.25 are happily accepted for muxing by both DVD-A 5.0 and 5.2, no transcoding.

I just tested with a short sample (1130frames) of 1920x1080x25i footage encoded by HCEnc 0.25.
2-Pass VBR 24,5Mbps-28Mbps. Muxing time 13s.
Both .isos mounted by VirtualClonedrive, both playable by PowerDVD 7.3.

>here at my system b-pyramid strict has been accepted by DVD-A 5.0 and 5.2 on progressive AVC streams.

Yes, well, I've had such streams ACCEPTED too by DVDAP5.0, but then its output would play-back jerkily at misc points in the video. Instead of playing frames perfectly in succession, the playback would jump-back a frame at times. I worked hard trying to figure this out and --b-pyramid none was the only solution. This was with an older version of x264 of course but I doubt it's been fixed as I believe it to be a DVDAP issue.

The interlaced MPEG2 that errored-out for me (at DVDAP mux time) was from a commercial TV series DVD (720x480).

IMO, b-pyramid is soooo unnecessary at bitrates >2Mbs, which yours obviously are.

What b-pyramid does is use existing b-frames as surrogate references for new b-frames, thus the "pyramid" analogy. It gives a slight compression advantage at the expense of longer renders and strain on the decoder. Not really worth it afaiac.

But how is even a "slight compression advantage" relevant in any way if the result doesn't play-back properly?

I'm just warning Emulgator to look carefully at his muxes if he's used b-pyramid at all. And AFAIK you do have to explicitly turn it off now in x264 if you use --bluray-compat.

About b-pyramid: Thanks for the warning. Of course a longer muxing and playability check on my side will have to follow anyway, but for now my time is still too limited.
First I wanted to address muxability issues.
There were other faults as well back then (x264->DVD-A5.0) like being unable to rewind properly.
I will report back when I have more time.

Well I may have to eat my words. I went back to my test setup and tried it again, this time with latest r1995 and --bluray_compat which includes bpyramid, and muxing again with Sony DVDAP I don't see the frame playback problem in the resulting .m2ts any more.

My earlier testing was from Sep-10 with x264 r1703, and although I don't recall any specific mention of changes to bpyramid along the way, it appears something has changed in x264 and the problem is gone (still using same DVDAP5.0b (build 180).

So I look forward Emulgator to your further testing and confirmation of "no jerkiness in motion sequences".

I'm new to DVDA and having no luck with H264 AVC from Edius and other encoders. Everytime during build blu-ray I get the message below and others are getting.

File name STREAM/00000.m2ts
Status: TSWrapper.dll::CTSWrapper::ProcThreadMain::This program has a bug. -m_ptsOfNextGOP is empty.

A forum search reveals this problem has existed since 2009. What is the latest? Is this still a bug, related to bit rate?

Any suggestions or workarounds welcome (except letting DVDA transcode to a lower bit rate) I dont want to spend the time or loose quality.

Thanks
Mark

Mark,
DVD Architect is designed to use compliant streams from its own encoders in Vegas. Re-encoding only becomes necessary when the stream size exceeds disc capacity. Compatibility with third party products may or may not occur, but is not a focus of Sony's development effort, as mentioned in my first response in this thread.

From reading quite a number of forum posts on this subject, the reason for my previous post is many of the posts I read date back to 2 years ago. I wonder if the latest releases of Vegas and DVDA are still circumventing the bug (Sony have acknowledged) by restricting Vegas peak data rate and limiting its AVC encode presets? In the latest versions I gather you cannot output from Vegas at 25 mb/s AVC and have DVDA pass through without recompressing?

MPEG2 works fine at 25 mb/s. Its just AVC as far as I can gather and have found with my own experience.