1280x720p25 on BD

[latet]

Hi,

I was just reading this: http://sites.google.com/site/x264bluray/home/720p-encoding

For Blu-ray, how important for 1280x720p25 is setting the flag:
--pulldown double
I mean - in the real world - are there many BD stand-alone players that refuse to play if rendered without this setting?
BTW: is it olny a flag (like: --fake-interlaced) or it truly doubles the frames?

Thanks,

latet

[Gser]

It's only a flag, so there's no point in not using it. And since it's only doubling each frame, you won't get any jitter.

[latet]

It's only a flag, so there's no point in not using it. And since it's only doubling each frame, you won't get any jitter.

I used it but it's not shown in the info log:


Format : Matroska
File size : 484 MiB
Duration : 4mn 40s
Overall bit rate : 14.5 Mbps
Writing application : HandBrake 0.9.5
Writing library : libmkv 0.6.4.1

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Format settings, GOP : M=1, N=16
Codec ID : V_MPEG4/ISO/AVC
Duration : 4mn 40s
Bit rate : 14.0 Mbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.606
Stream size : 467 MiB (96%)
Writing library : x264 core 112
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1
/ psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16
/ chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2
/ threads=3 / sliced_threads=0 / slices=4 / nr=0 / decimate=1
/ interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=1 / weightb=1 / open_gop=0
/ weightp=2 / keyint=25 / keyint_min=2 / scenecut=40
/ intra_refresh=0 / rc_lookahead=25 / rc=crf / mbtree=1
/ crf=10.0 / qcomp=0.60 / qpmin=3 / qpmax=51 / qpstep=4
/ vbv_maxrate=40000 / vbv_bufsize=30000 / crf_max=0.0
/ ip_ratio=1.40 / aq=1:1.00 / nal_hrd=none
Language : English
Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

Audio
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Codec ID : A_AC3
Duration : 4mn 40s
Bit rate mode : Constant
Bit rate : 224 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 7.48 MiB (2%)


Here: http://sites.google.com/site/x264bluray/issues-with-certain-players they wrote:
TSmuxer does not support any of the --pulldown options
Does it mean that tsmuxer (which, as I believe, is used by Handbrake, that I used) simply resets this flag?

P.S.
I also notices that the file which log is shown above response quickly to moving the "seek" slider (in softplayer) while the one below makes me wait like 2 secs after moving the slider. Which setting may be responsible?


Format : Matroska
File size : 420 MiB
Duration : 4mn 40s
Overall bit rate : 12.6 Mbps
Writing application : HandBrake 0.9.5
Writing library : libmkv 0.6.4.1

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 4mn 40s
Bit rate : 12.1 Mbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.525
Stream size : 404 MiB (96%)
Writing library : x264 core 112
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1
/ psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16
/ chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0
/ deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2
/ threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=2
/ b_adapt=2 / b_bias=0 / direct=1 / weightb=1 / open_gop=0
/ weightp=2 / keyint=250 / keyint_min=25 / scenecut=40
/ intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1
/ crf=10.0 / qcomp=0.60 / qpmin=3 / qpmax=51 / qpstep=4
/ ip_ratio=1.40 / aq=1:1.00
Language : English
Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

Audio
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Codec ID : A_AC3
Duration : 4mn 40s
Bit rate mode : Constant
Bit rate : 224 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 7.48 MiB (2%)

[sneaker_ger]

For fully compliant encodes you cannot use Handbrake, as you will need x264's ES output while Handbrake only outputs mp4 or mkv. If you don't have access to a different muxer than tsMuxer you could use a hard pulldown or use 1080p with fake interlaced as a workaround sacrificing some quality.

The second file seeks slower because its keyframe interval is ten times the one of the first file.

/edit: Do you actually want to output to Blu-Ray or do you want to output to Matroska? After reading your post again I am under the impression that you don't want to create a Blu-Ray structure, but simply .mkv files. Handbrake does not include tsMuxer nor can it output such structures. If you just want to create Matroska files, you don't have to deal with things like pulldown. Those are only needed for people who want to author real Blu-Ray, e.g. mastering a Blu-Ray to be sold commercially.

[latet]

For fully compliant encodes you cannot use Handbrake, as you will need x264's ES output while Handbrake only outputs mp4 or mkv. If you don't have access to a different muxer than tsMuxer you could use a hard pulldown or use 1080p with fake interlaced as a workaround sacrificing some quality.


Is this a confirmation that most BD players (and PS3) won't play 720p25?

Besides tsMuxer, are any other free muxers?

multiAVCHD uses tsMuxer, isn't it? Won't 720p25 BD discs prepared with multiAVCHD play?


/edit: Do you actually want to output to Blu-Ray or do you want to output to Matroska? After reading your post again I am under the impression that you don't want to create a Blu-Ray structure, but simply .mkv files. Handbrake does not include tsMuxer nor can it output such structures. If you just want to create Matroska files, you don't have to deal with things like pulldown. Those are only needed for people who want to author real Blu-Ray, e.g. mastering a Blu-Ray to be sold commercially.

My plan was: make a high-quality .MKV files for storage and archiving then - when there are 20-30 of them ready - import .mkv files to multiAVCHD and author and burn a Blu-ray disk. I definitely won't sell it commercially, but you never know to whom you will want to send it in future... That's why I thought it would be good to have inside the .mkv files I'm making now, video streams that could be easily (without re-encoding) used to make BD compilations.

If it is a bad plan - please advise me what to do. Most of my video footage is 1208x720p25.

Thank you.

[sneaker_ger]

Is this a confirmation that most BD players (and PS3) won't play 720p25?

No, it's not.

Besides tsMuxer, are any other free muxers?

None that I know of. But even the expensive muxers don't support mkv input.

multiAVCHD uses tsMuxer, isn't it?

Yes.

Won't 720p25 BD discs prepared with multiAVCHD play?

I don't know as I'm not really familiar with it. Maybe someone else can answers these.

My plan was: make a high-quality .MKV files for storage and archiving then - when there are 20-30 of them ready - import .mkv files to multiAVCHD and author and burn a Blu-ray disk. I definitely won't sell it commercially, but you never know to whom you will want to send it in future... That's why I thought it would be good to have inside the .mkv files I'm making now, video streams that could be easily (without re-encoding) used to make BD compilations.

If it is a bad plan - please advise me what to do. Most of my video footage is 1208x720p25.

Well, you won't get 100% compatible Blu-Ray structures from the mkv files and they will probably not work in all players. With more and more Blu-Ray players supporting mkv you might as well just burn the mkvs to data discs - but they won't work on older players or the PS3.
What to choose? I do not know - it's a dilemma.

[Blue_MiSfit]

obe-vod will encode with x264 directly to a standards compliant TS, using libmpegts!

Derek

[kieranrk]

obe-vod will encode with x264 directly to a standards compliant TS, using libmpegts!

Except Blu-ray has a different buffering model and lots of other random files so probably worth a different application.

[Ghitulescu]

Is this a confirmation that most BD players (and PS3) won't play 720p25?

First of all your question is a lil'bit confusing, considering your initial post.

Since 720p25 is not in the BD books it is not mandatory supported by the BD players in BD format (or, it it's supported then the manufacturer gave you a gift). AFAIK not even AVCHD allows 720p25. Some BD players play however other formats, like MKV or DivX (in HD), and could in theory support this 720p25. Ask the manufacturer of your choice.

The standards are there to assure compatibility. Without standards (or too many, like in the PC world) it's chaos (like in PC world).

PS: Are you one of those that want to have Avatar 3D in 700MB with no quality loss? :p

[Blue_MiSfit]

Except Blu-ray has a different buffering model and lots of other random files so probably worth a different application.

That's a very good point. How come I didn't think of that?

Sounds like another awesome potential application of libmpegts though, huh?

Derek

[kieranrk]

That's a very good point. How come I didn't think of that?

Sounds like another awesome potential application of libmpegts though, huh?

Derek

Might be best to do it in libavformat though. The important thing about libmpegts is on the fly reconfig for realtime streams.

[drmpeg]

Except Blu-ray has a different buffering model...
No. Blu-Ray and AVCHD or any .m2ts file follows the same T-STD buffering model as a regular constant bitrate 188-byte Transport Stream. However, instead of sending stuffing packets (which would be a waste of storage space) to maintain the constant bitrate, a packet arrival time stamp is used instead.

If you have a T-STD compliant 188-byte TS muxer, you can generate a T-STD .m2ts by just doing the following:

1) generate but then discard stuffing packets.

2) place the normalized lower 30 bits of the PCR of each packet into the arrival_time_stamp field.

Ron

[latet]

I don't understand many things from your replies (not the language problem, just me being so unexperienced: buffering models, libavformat, obe-vod, libmpegts - I'm not familiar with any of these).

Probably the easiest way for me to solve the (potential) problem is to physically double the frames 25p-->50p. Should be easy for me to do it in Virtualdub as I still have all the source files in .avi/huffyuv.

But in the meantime, I managed to render 720p25 video with "pulldown=double" (I used meGUI) and then to import it via multiAVCHD to BD compilation. The "frame doubling" flag is still in the final .m2ts file (surprised?), but there is something else (probably) wrong with it as it dosn't play smooth on my PC. This is the log:


Complete name : F:\multiavchdoutput\AVCHD\BDMV\STREAM\00000.m2ts
Format : BDAV
Format/Info : Blu-ray Video
File size : 763 MiB
Duration : 3mn 37s
Overall bit rate : 29.4 Mbps
Maximum Overall bit rate : 35.5 Mbps

Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Frame mode : Frame doubling
Format settings, GOP : M=2, N=32
Codec ID : 27
Duration : 3mn 37s
Bit rate mode : Variable
Bit rate : 28.3 Mbps
Maximum bit rate : 40.0 Mbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 1.226
Stream size : 733 MiB (96%)
Writing library : x264 core 112 r1867 22bfd31

Encoding settings : cabac=1 / ref=4 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1
/ me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / sliced_threads=0
/ slices=4 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1
/ open_gop=2 / weightp=0 / keyint=25 / keyint_min=2 / scenecut=40 / intra_refresh=0 / rc_lookahead=25 / rc=crf / mbtree=1 / crf=10.0 / qcomp=0.60
/ qpmin=0 / qpmax=51 / qpstep=4 / vbv_maxrate=40000 / vbv_bufsize=30000 / crf_max=0.0 / nal_hrd=vbr / ip_ratio=1.40 / aq=1:1.00

Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177


Does it look like it should work on most hardware?


P.S.
What do you think about vso_avchd_editor. Someone told me he uses it to "rebuild" the output of multiAVCHD, achieving this way better hardware compatibility. Do you also use this trick?

Thanks,

latet

[shon3i]

but there is something else (probably) wrong with it as it dosn't play smooth on my PC.This is because Tsmuxer incorrectly mux pulldown stream. Like stay on x264BD page that TSmuxer does not support any of the --pulldown options

Best soultion for you is to slowdown video and audio to 24fps.

[latet]

Best soultion for you is to slowdown video and audio to 24fps.

How to slow down audio without any audible quality loss? I have zero experience in audio processing. Any recommended tools?

In the meantime - I'm testing "hard" 25-->50 fps conversion and it feels promising. The output files (mkv at this stage) are just a little larger that 25p. No surprise - x.264 is an intelligent encoder. Just one issue - BitrateViewer doesn't show true information about 50p MKV files.

Later, I'll try to import 50p to multiAVCHD and see what happens.

[shon3i]

How to slow down audio without any audible quality loss? I have zero experience in audio processing. Any recommended tools?What is source audio format?

[latet]

What is source audio format?

Well, it depends. In original .avi/huffyuv files there is PCM. But I won't keep them forever, because of the size. I may export and keep .wav's though.
But for my main HD archive format I have .MKV/x.264 files with AC3 sound (unfortunately MKV can't have PCM).

I have also many much older clips that have mp3 sound.

[latet]

This is the .MKV/AVC file I made with Handbrake, from the 50p (hard frame doubling) .avi/huffyuv source. Is there anything in the log that could make me worry? I plan to import this .MKV file into multiAVCHD (to tell the truth, I don't have any other BD authoring tool) and prepare BD compilation. Do you think it should be compatible enough?


Complete name : F:\test_720p50hard.mkv
Format : Matroska
File size : 628 MiB
Duration : 3mn 37s
Overall bit rate : 24.2 Mbps
Writing application : HandBrake 0.9.5
Writing library : libmkv 0.6.4.1

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Format settings, GOP : M=1, N=32
Codec ID : V_MPEG4/ISO/AVC
Duration : 3mn 37s
Bit rate : 23.5 Mbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 50.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.510
Stream size : 610 MiB (97%)
Writing library : x264 core 112

Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1
/ psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11
/ fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / sliced_threads=0 / slices=4 / nr=0 / decimate=1 / interlaced=0
/ constrained_intra=0 / bframes=3 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2
/ keyint=50 / keyint_min=5 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=17.0 / qcomp=0.60 / qpmin=3 / qpmax=51 / qpstep=4 / vbv_maxrate=40000
/ vbv_bufsize=30000 / crf_max=0.0 / ip_ratio=1.40 / aq=1:1.00 / nal_hrd=none

Language : English
Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

Audio
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Codec ID : A_AC3
Duration : 3mn 37s
Bit rate mode : Constant
Bit rate : 224 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 5.81 MiB (1%)

[nm]

(unfortunately MKV can't have PCM).
Sure it can.


How to slow down audio without any audible quality loss?

If you have 48 kHz audio and want to synchronize it to slowed down 24p video, fake that the audio has a samplerate of:

48000 Hz * 0.96 = 46080 Hz

Then resample the 46080 Hz audio to 48 kHz. Quality is determined by the resampling algorithm. Of course it's also better to use a higher-rate audio as the source if such a stream is available.


If you want to slow the video down to 24000/1001 fps instead of even 24 fps, use this multiplier for the samplerate:

1-(25-24000/1001)/25 = 1 - 41/1001 ~ 0.959040959041

This is the .MKV/AVC file I made with Handbrake, from the 50p (hard frame doubling) .avi/huffyuv source. Is there anything in the log that could make me worry? I plan to import this .MKV file into multiAVCHD (to tell the truth, I don't have any other BD authoring tool) and prepare BD compilation. Do you think it should be compatible enough?
I don't think so. You are missing nal-hrd, for example, and MKV can't be used as an intermediate format for Blu-ray output. Encode to a raw elementary stream with x264 CLI and use the settings listed on this site: http://sites.google.com/site/x264bluray/

[latet]

Sure it can.
Nice to know. Pity Handbrak doesn't offer it.


If you want to slow the video down to 24000/1001 fps instead of even 24 fps

Should I want that? Is 24000/1001 safer that even 24?

You are missing nal-hrd
What is it responsible for?


and MKV can't be used as an intermediate format for Blu-ray output.
What do you mean by "intermediate"? What is wrong with it? Does it destroy the video stream?


Encode to a raw elementary stream with x264 CLI and use the settings listed on this site: http://sites.google.com/site/x264bluray/
Well, I tried to apply those settings to Handbrake, but it seems like I missed (or changed) some.

Let's say I make MKV's first and later on use x264 CLI on them, to re-encode (pity it's so slooow...) and get the proper raw elementary stream? Will it be OK?

If my MKV's have AC3 sound, can I extract the sound-track using TSmuxer? (I won't use pulldown, I'll prepare real 50p sources first).

And finally - let's say I have prepared (as you advised) what program do you recommend to join video+audio back together and do some authoring? Would multiAVCHD be good enough for both?

Thanks,

latet

[latet]

OK then, I did what you kindly told me to, exactly like it's recommended here: http://sites.google.com/site/x264bluray/home/720p-encoding

I did this:

x264.exe --bitrate 24000 --preset veryslow --tune film --weightp 1 --bframes 3 --nal-hrd vbr --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 50 --b-pyramid strict --slices 4 --ref 6 --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 1 -o output.264 d:\720p50_source.avi

x264.exe --bitrate 24000 --preset veryslow --tune film --weightp 1 --bframes 3 --nal-hrd vbr --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 50 --b-pyramid strict --slices 4 --ref 6 --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 2 -o output.264 d:\720p50_source.avi

The second pass took like AGES (like 5 hours, and that was only 3:45 min. movie!!!).

This is the info log of the output.264 file:


Format : AVC
Format/Info : Advanced Video Codec
File size : 622 MiB
Video
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 5 frames
Format settings, GOP : M=1, N=32
Bit rate mode : Variable
Bit rate : 24.0 Mbps
Maximum bit rate : 40.0 Mbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Writing library : x264 core 112 r1867 22bfd31
Encoding settings : cabac=1 / ref=6 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10
/ psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=24
/ chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3
/ threads=3 / sliced_threads=0 / slices=4 / nr=0 / decimate=1
/ interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0
/ weightp=1 / keyint=50 / keyint_min=5 / scenecut=40
/ intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1
/ bitrate=24000 / ratetol=1.0 / qcomp=0.60 / qpmin=0
/ qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5
/ vbv_maxrate=40000 / vbv_bufsize=30000 / nal_hrd=vbr
/ ip_ratio=1.40 / aq=1:1.00

Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177


Is it 100% OK? (I don't see any FPS info in the log, strange, isn't it? And I don't know why is ReFrames = 5 frames, as it was set to 6 (--ref 6), BTW isn't 3 or 4 the safest? Also, the log says that max. bitrate is 40000, but according to Bitrate Viewer there are 2 or 3 needle-like peaks up to 45000 - but I guess it is nothing to worry about.

Then - I used TSmuxer to join it with .ac3 audio and created .m2ts output. Is such output the best intermediate file for Blu-ray authoring? This is the info log of the .m2ts file:


ID : 1 (0x1)
Complete name : C:\720p50_ac3_test.m2ts
Format : BDAV
Format/Info : Blu-ray Video
File size : 658 MiB
Duration : 3mn 37s
Overall bit rate : 25.3 Mbps
Maximum Overall bit rate : 35.5 Mbps

Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 5 frames
Format settings, GOP : M=1, N=32
Codec ID : 27
Duration : 3mn 37s
Bit rate mode : Variable
Bit rate : 24.0 Mbps
Maximum bit rate : 40.0 Mbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Stream size : 626 MiB (95%)
Writing library : x264 core 112 r1867 22bfd31

Encoding settings : cabac=1 / ref=6 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10
/ psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=24
/ chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3
/ threads=3 / sliced_threads=0 / slices=4 / nr=0 / decimate=1
/ interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0
/ weightp=1 / keyint=50 / keyint_min=5 / scenecut=40
/ intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1
/ bitrate=24000 / ratetol=1.0 / qcomp=0.60 / qpmin=0
/ qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5
/ vbv_maxrate=40000 / vbv_bufsize=30000 / nal_hrd=vbr
/ ip_ratio=1.40 / aq=1:1.00

Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

Audio
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Codec ID : 129
Duration : 3mn 37s
Bit rate mode : Constant
Bit rate : 224 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 5.81 MiB (1%)


I hope it is OK. (Strangely still no direct FPS info).

Thank you very much for your kind help and advise.

Latet

[sneaker_ger]

The second pass took like AGES (like 5 hours, and that was only 3:45 min. movie!!!).

That's normal for preset veryslow, 720p50 and your dual core. You can choose a faster preset of course.

Is it 100% OK? (I don't see any FPS info in the log, strange, isn't it?

It's OK. You can add "--fps 50" if you want to make sure it chooses the correct framerate.

And I don't know why is ReFrames = 5 frames, as it was set to 6 (--ref 6) BTW isn't 3 or 4 the safest?

It's normal, bpyramid lowers the dpb. You only have to go as low as 4 for 1080p.

Also, the log says that max. bitrate is 40000, but according to Bitrate Viewer there are 2 or 3 needle-like peaks up to 45000 - but I guess it is nothing to worry about.

Yes, it's OK to have small spikes. x264 will make sure the vbv model is followed.

Then - I used TSmuxer to join it with .ac3 audio and created .m2ts output. Is such output the best intermediate file for Blu-ray authoring?

AFAIK yes. But untick "Add picture timing info" and "Continually insert SPS/PPS" in tsMuxer.

[latet]

That's normal for preset veryslow, 720p50 and your dual core. You can choose a faster preset of course.

From what I've read about the presets I assume that faster ones lowers quality in bitrate modes. I wouldn't like that. On the other hand - Handbrake is like 30x faster... why? It also uses x264.exe, doesn't it? And to tell the truth - I can't see any difference in the quality (at the same bitrates). If Handbrake is so fast only thanks to using faster profiles, I could risk using them in x264 CLI...

But untick "Add picture timing info" and "Continually insert SPS/PPS" in tsMuxer.

I can't untick something that I can't find. I have tsMuxer GUI 1.10.6. There are no such check-boxes in any of the "tabs" (Input, General, Blu-ray, Splt&cut, Subtitles, Donate, About). Where are the two you mention?

In the General/General there are two other checkboxes that I dont know what to do with:
- use async i/o
- blu-ray audio PES

Thanks.

[nm]

From what I've read about the presets I assume that faster ones lowers quality in bitrate modes.
Yes, but the difference is probably not as large as you might think, especially at high bitrates such as yours. Try and see.

You can also use CRF instead of 2-pass, as long as you keep VBV and the other settings.

If Handbrake is so fast only thanks to using faster profiles

Yes. IIRC, it uses pretty much the defaults (--preset medium).

[sneaker_ger]

http://www.abload.de/img/spspsxv.png

[latet]

Oh, there they are. Thanks. I didn't see them, because I had clicked on the audio stream in the Tracks section. So I will have to do it again.

Just out of being curious - what if I don't uncheck them? What are "picture timing info" and "SPS/PPS"? Why are they not welcome?

[Groucho2004]

But untick "Add picture timing info" and "Continually insert SPS/PPS" in tsMuxer.

IIRC, if the stream was encoded with "nal-hrd", TSMuxer won't modify it whether they are checked or not.

[sneaker_ger]

IIRC, if the stream was encoded with "nal-hrd", TSMuxer won't modify it whether they are checked or not.

I once read otherwise, but that was long ago. Anyone here to verify this?

/edit:
http://forum.doom9.org/showpost.php?p=1427862&postcount=4

Not sure what's correct, though.

[Groucho2004]

I'm quite sure about it.

TSMuxer prints messages when it modifies streams:

H264 bitstream changed: insert nal unit delimiters
H264 bitstream changed: insert pict timing and buffering period SEI units

This happens whether the two options are selected or not.

When I encode for AVCHD I use "nal-hrd" and "pic-struct" with x264 and with these streams I don't get the messages in TSMuxer which lets me believe that it doesn't modify the stream.

Possibly someone else has more insight.

[latet]

If I keep the two checkboxes checked I get:


SmartLabs tsMuxeR. Version 1.10.6 http://www.smlabs.net
Decoding H264 stream (track 1): Profile: High@4.1 Resolution: 1280:720p Frame rate: 50
H.264 stream does not contain fps field. Muxing fps=50
B-pyramid level 1 detected. Shift DTS to 2 frames
Processed 10886 video frames
Mux successful complete.
Muxing time: 8 sec


if I uncheck them I get:


SmartLabs tsMuxeR. Version 1.10.6 http://www.smlabs.net
Decoding H264 stream (track 1): Profile: High@4.1 Resolution: 1280:720p Frame rate: 50
H.264 stream does not contain fps field. Muxing fps=50
B-pyramid level 1 detected. Shift DTS to 2 frames
Processed 10886 video frames
Mux successful complete.
Muxing time: 13 sec


As you can see - there is no "H264 bitstream changed..." message in any case. The video was rendered this way:

x264.exe --bitrate 24000 --tune film --weightp 1 --bframes 3 --nal-hrd vbr --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 50 --b-pyramid strict --slices 4 --ref 6 --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 1 -o name.264 d:\name50p.avs

But I get this "H264 bitstream changed..." message when I try to mux mkv files made by Handbrake, and after muxing the .mwts result is truly very poor - they won't play smooth at all.

So - should I uncheck the two checkboxes or not?

BTW: H.264 stream does not contain fps field. Muxing fps=50 - isn't it a problem? It guesses right (50fps). But maybe I'd be better off adding "--fps 50" to encoder's parameters?

What exactly is nal-hrd?

[Groucho2004]

Should I uncheck them or not?

It seems that it won't make any difference. From my tests I conclude that TSMuxer adds timing info if it's not in the stream and doesn't add it if the stream has the info already - whether these options are selected or not.

BTW: H.264 stream does not contain fps field. Muxing fps=50 - isn't it a problem? It guesses right (50fps). But maybe I'd be better off adding "--fps 50" to encoder's parameters?

Adding "--fps" doesn't make any difference. I think TSMuxer simply doesn't read the field properly.

[sneaker_ger]

Yes, it seems that you are correct. I did a short test with and without those options checked and the resulting files were bit identical as long as --nal-hrd vbr had been set. I've been spreading nonsense, but at least it didn't break anything...