Choppy playback of Vegas HD files on PS3

DGates wrote on 8/13/2009, 12:05 AM

Matt,

You can't compare what you can encode with Vegas to some Hollywood Blu-Ray movie. The technology they are using most likely cost 100K+ easily. In addition to all the specialists they hire to design and encode it.

Now compare that with the guy in his underwear trying to do the same with Sony Vegas.

apit34356 wrote on 8/13/2009, 1:05 AM

check MarcoB post about re-muxing

Marco. wrote on 8/13/2009, 1:39 AM

"When I start the process, it goes throgh the preparation stage and then get "An error occurred while preparing the compilation" with details as"

This is a known issue of current version of DVD Architect Pro.

Marco

Marco. wrote on 8/13/2009, 1:45 AM

When a longer file rendered as AVCHD in Vegas Pro plays choppy after some minutes on any kind of media player just try remuxing the rendered file.

We had same problem and remuxed the rendered files with TSMuxer. This does not affect the video or audio itself and the muxing process is very fast - just like copying the file.

Marco

john-beale wrote on 8/13/2009, 9:02 PM

Many thanks to MarcoB! As you suggested, I used the SmartLabs tsMuxeR http://www.smlabs.net/tsmuxer_en.html to remux my problem M2TS file (very fast operation). I selected "M2TS muxing" and left the default boxes checked "Add picture timing info" and "Continually insert SPS/PPS". The M2TS file as generated by V9a was 450,054,144 bytes in size, and the remuxed version was actually slightly smaller, 449,531,904 bytes.

The remuxed video plays perfectly on the PS3. No stuttery motion, and FF/REV works fine also. The problem is solved.

It seems to me now there is some error in how V9a muxs M2TS files, at least with the default settings on the Sony AVC 1080i 16 Mbps preset.

MattAdamson wrote on 8/18/2009, 6:48 AM

Hi Marco

Thanks for your advice re

"This is a known issue of current version of DVD Architect Pro."

Is there a workaround then or solution to this If I want to create DVDs / blu rays from AVCHD files that I've rendered?

Re tsMuxer I'm actually just going to try this and experiment with some files however I'm puzzled as to what this is really doing to make a difference.

Marco. wrote on 8/18/2009, 7:49 AM

This refers to my other post, doesn't it?

The only workaround for now is either rendering to MPEG instead or let DVD Architect do the AVC render.

Marco

MattAdamson wrote on 8/18/2009, 8:04 AM

Hi Jbeale

Which format are you rendering to in vegas to playback well on the PS3?

MattAdamson wrote on 8/18/2009, 9:00 AM

Thanks Marco

"The only workaround for now is either rendering to MPEG instead or let DVD Architect do the AVC render."

Given the issues were discussing in this thread then related to choppy AVC files and requiring the use of tsmuxer to post process them I guess using DVD architect to do the AVC render isn't a workable solution then. I'll try rendering to MPEG then and using that as input in dvd architect studio

Although TBH that isn't ideal having just trying rendering some raw M2TS AVCHD files from my CANON HF10 using MPEG rendering it takes up 1.23GB and AVCHD was about 0.9GB so a lot bigger

MattAdamson wrote on 8/18/2009, 1:15 PM

Guys

Perhaps the output from tsmuxer gives a clue as to what vegas isn't doing in the generated m2ts file

"SmartLabs tsMuxeR. Version 1.10.6 http://www.smlabs.net
Decoding H264 stream (track 1): Profile: High@4.0 Resolution: 1920:1080i Frame rate: 25
H.264 stream does not contain fps field. Muxing fps=25
Decoding AC3 stream (track 2): Bitrate: 192Kbps Sample Rate: 48KHz Channels: 2
B-pyramid level 2 detected. Shift DTS to 3 frames
Processed 12563 video frames
Mux successful complete.
Muxing time: 53 sec"

i.e. the line

H.264 stream does not contain fps field. Muxing fps=25

Shouldn't the file always contain the fps field and if it's not present could this be attributing to the choppy and fast behaviour were seeing sometimes perhaps because the PS3 can't recognise the no of fps in the video?

I've just call Sony tech support and passed on this information to them. They mentioned a very similar issue had been logged and was being looked into by 2 teams so hopefully this information will help them provide a quicker resolution.