shon3i

SAR is MANDATORY option for blu-ray, look here at 2.1 chapter http://forum.doom9.org/showthread.php?t=154533, for all mandatory options for BD, they should be always used when encoding for BD. SAR should not fix b-pyramid problem, but i suggest you to use it, since panasonic is very strict, and one of player that really follow BD specs. You should use b-pyramid always if you get some quality gain.

That is same as directly encode to MKV. So this option definitly will not work as i said. You need to encode directly to raw 264, otherwise, x264 will calculate differenet AUD for target container, which after Tsmuxer completly broke, demuxing mkv to elementary (raw 264) will not change that calculations, and stream practically is useless, and make unplayable on panasonic players.

It will work, since all calculations are ok, unless you use MKV or other container in that process as intermediate file, that will rush compatibility, and make stream unplayable.

JoeH

First test:
Remuxed x264 demo file 0003.m2ts using all of TSMuxer's default settings. The Panasonic played it just fine.

MUXOPT --no-pcr-on-video-pid --new-audio-pes --blu-ray --vbr --auto-chapters=5 --vbv-len=500
V_MPEG4/ISO/AVC, "F:\4 Peliculas\X264 Demo Disk\BDMV\STREAM\00003.m2ts", fps=24, insertSEI, contSPS, track=4113
A_DTS, "F:\4 Peliculas\X264 Demo Disk\BDMV\STREAM\00003.m2ts", track=4352, lang=eng

JoeH

Second test

I've output 4 different streams - 2 are .MKV, 2 are .264. One of each container type has SAR set, the other does not.

Just tested .MKV with no SAR - this is identical to what didn't work before. As expected, it did not work. I ran this just as a control.

JoeH

Third test

.264 stream without SAR set. It works just fine in the Panasonic.

Fourth test

.MKV stream with SAR set. Does not play.

Fifth test

.264 stream with SAR set.

Results summary - Panasonic players will play streams from TSMuxer using BPyramid --strict option as long as the original input is a .264 stream and not an MKV stream. This will work with default TSMuxer options, and works regardless of whether the SAR option is correctly configured or not.

rack04

I wouldn't summarize this as all Panasonic's. My BD-35 doesn't have any problem playing back remuxed mkv's with --strict.

shon3i

Here is not question that what will work or not. It's simple, MKV/MP4 output (or demuxed from MKV/MP4) should never use if target is BD, regardless that some player play or not, that stream will never pass initial verification, and it's completly broken.

rack04

Actually that is exactly the question. JoeH said that Panasonic's do not play files that have been remuxed from mkv and I stated that my BD-35 will.

shon3i

Well it's not question since is not legal operation, end of story. In past we have people with BD-35 which have exactly same problem (in BDrebuilder thread). From this point maybe panasonic update their software, but still why we should expect something to work, when is come broken.

JoeH

I also have a BD35, and the playback problems are identical on it as on the BD60 with the rendering / muxing method I use.

laserfan

I continue to struggle with understanding the tsMuxeR setting of --vbv-len wrt the --vbv-init (default 0.9) setting in x264, along with bufsize and maxrate:

Under what circumstances (if any) should the --vbv-len parameter in tsMuxeR be altered from default 500ms? Any reason to alter it, or the 0.9 default of vbv-init if my output is to BD standard?

kieranrk

(bufsize/bitrate)*1000

vbv-init is not relevant

__________________
Authoring Professional Blu-rays with x264 - Open Broadcast Encoder

shon3i

As in readme written that is used only in conjunction with -cbr, don't touch it, because has no effect.

Sharc

Does stream damage come with mkv/mp4 muxing or with demuxing?

shon3i

tsmuxer is that who will broke stream, but MKV or MP4 muxer will strip/revrite AUD when mux, and will not revert back on demux. And since Tsmuxer have some not perfect mechanism to restore all need information for bd, instead that will violate all aud data.

Sharc

@shon3i
Thank you. A new revision of TSMUXER would be nice ....

shon3i

Yep, long time, tsmuxer currently have problem with pulldown streams, an who know what else, i think we can make pretty list of bugs. I think is time for new muxer, opensource idealy to be easily maintained .

Anyway, mkv or mp4 output is not for BD, only raw 264 or maybe ts/mpg. So any aplication that mux mkv/mp4 into BD structure, definitly use some (ugly) hack.

JoeH

OK, I just ran another test that I think is very important to note.

I muxed the .264 output with BPyramid Strict into an MKV container, remuxed with TSMuxer into Bluray folders and burnt. It plays perfectly.

So, that means that BPyrmaid -Strict only causes problems with Panasonics when X264 outputs MKV format directly. As long as you output .264 from X264, you can then remux into MKV and eventually later into Bluray without problems.

bob0r

So,
x264.exe .264 > .mkv > .m2ts = ok
x264.exe .mkv > .m2ts = bad?

What did you use to .264 > .mkv ?

shon3i

No

x264.exe .264 > BD = OK
x264.exe .mkv/.mp4 > BD = bad
x264.exe .264 > .mkv/.mp4 > .264 > BD = bad

@JoeH, yes it because x264 automaticly calculate what need for target container. But still your combination beside playing will never pass verification, and remuxing raw stream to container and back is not good combination, it maybe work with tsmuxer because use some hacks, but will never pass with comercial muxers. Don't do that.

bob0r

x264.exe .264 > BD

"because it is the only way to get correct AUD and HRD info"

That's why. (Asked in #x264)