I’ve encoded 21 episodes from the same BD set, using HandBrake and mkvmerge (3.3) to include subs. All episodes play perfect, except one, which gives black video. The subs shows in an off-color (should be white, but appear purple/pink.
The episode plays flawlessly at the pc with VLC.
Inspecting the media info the only diff that wonders me is that the format profile is High@L4.2 in the non-working file and High@L4.0 in the working file. Mediainfo is shown below.
Questions:
-
May it be this 4.2 that bothers the Live?
-
Is the format profile from the original movie, or introduced by HB or mkvmerge?
-
Any suggestions to fix it?
Cocovanna
Working file:
General
Complete name : G:\WDC\Backup\House\Sæson 6\15 Black Hole.mkv
Format : Matroska
File size : 2.11 GiB
Duration : 43mn 51s
Overall bit rate : 6 894 Kbps
Encoded date : UTC 2010-10-14 18:30:17
Writing application : mkvmerge v3.3.0 ('Language') built on Mar 24 2010 14:59:24
Writing library : libebml v0.8.0 + libmatroska v0.9.0
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Muxing mode : Container profile=Unknown@4.0
Codec ID : V_MPEG4/ISO/AVC
Duration : 43mn 51s
Bit rate : 5 247 Kbps
Width : 1 920 pixels
Height : 1 072 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.106
Stream size : 1.61 GiB (76%)
Writing library : x264 core 105 r1724 b02df7b
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=12 / 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=240 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=20.0 / qcomp=0.60 / qpmin=10 / 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 : DTS
Format/Info : Digital Theater Systems
Codec ID : A_DTS
Duration : 43mn 51s
Bit rate mode : Constant
Bit rate : 1 510 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Video delay : 10ms
Stream size : 474 MiB (22%)
Text
ID : 3
Format : VobSub
Muxing mode : zlib
Codec ID : S_VOBSUB
Codec ID/Info : The same subtitle format used on DVDs
Language : English
Non-working file:
General
Complete name : G:\WDC\Backup\House\Sæson 6\16 Lockdown.mkv
Format : Matroska
File size : 1.41 GiB
Duration : 43mn 57s
Overall bit rate : 4 606 Kbps
Encoded date : UTC 2010-10-14 18:31:17
Writing application : mkvmerge v3.3.0 ('Language') built on Mar 24 2010 14:59:24
Writing library : libebml v0.8.0 + libmatroska v0.9.0
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.2
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Muxing mode : Container profile=Unknown@4.2
Codec ID : V_MPEG4/ISO/AVC
Duration : 43mn 57s
Bit rate : 3 004 Kbps
Width : 1 920 pixels
Height : 1 104 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.059
Stream size : 945 MiB (65%)
Writing library : x264 core 105 r1724 b02df7b
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=12 / 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=240 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=20.0 / qcomp=0.60 / qpmin=10 / 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 : DTS
Format/Info : Digital Theater Systems
Codec ID : A_DTS
Duration : 43mn 57s
Bit rate mode : Constant
Bit rate : 1 510 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Video delay : 10ms
Stream size : 475 MiB (33%)
Text
ID : 3
Format : VobSub
Muxing mode : zlib
Codec ID : S_VOBSUB
Codec ID/Info : The same subtitle format used on DVDs
Language : English
Just noticed, that the non-working file has a height of 1104 (?) – this may explain why the Live rejects it (and why I had tiny black bars at the side when watching the episode from the pc).
I’ll check the format of the original …
Cocovanna
I’m thinking it’s because the WDTV doesn’t officially support that profile.
Fromt he specs:
H.264 MP@L4.1 and HP@4.1 up to 1920x1080p24, 1920x1080i30, or 1280x720p60 resolution.
No mention of HP@4.2.
I’m unsure how many of the other files that are 4.2, I’m pursuing the “too-high” theory first …
Anyway, the original file is 1920*1080, and I can’t see anything that should give a “weird” aspect ratio. In HandBrake, Picture Tab, the size is shown also as 1920*1080 – but changed to 1920*1104 in the fields below, where I can change the width ? The only way I can make HB create a 1920*1080 output is by setting Anamorphic to None, remove tick in Keep Aspect Ratio and then lower 1104 to 1080. I am unable to change the size at all without changing Anamorphic, and the width changes down too (to 18xx something) if the Keep Aspect Ratio is ticked.
Any thoughts? Why is this (and for this episode only)? Where does this (supposedly wrong?) aspect information come from?
(I’ll be back with the result of the revised HB conversion)
Cocovanna
Original file mediainfo (I’ve tried to remove the secondary video track with tSmuxer before HB, but it doesn’t change anything):
General
ID : 0
Complete name : I:\00804.m2ts
Format : BDAV
Format/Info : Blu-ray Video
File size : 9.88 GiB
Duration : 43mn 58s
Overall bit rate : 32.2 Mbps
Maximum Overall bit rate : 48.0 Mbps
Video #1
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : VC-1
Format profile : AP@L3
Codec ID : 234
Duration : 43mn 57s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Video #2
ID : 6912 (0x1B00)
Menu ID : 1 (0x1)
Format : VC-1
Format profile : AP@L2
Codec ID : 234
Duration : 43mn 57s
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Standard : NTSC
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Audio #1
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : DTS
Format/Info : Digital Theater Systems
Format profile : MA
Muxing mode : Stream extension
Codec ID : 134
Duration : 43mn 57s
Bit rate mode : Variable
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Audio #2
ID : 6656 (0x1A00)
Menu ID : 1 (0x1)
Format : DTS
Format/Info : Digital Theater Systems
Format profile : Express
Codec ID : 162
Duration : 43mn 57s
Bit rate mode : Constant
Bit rate : 192 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Stream size : 60.4 MiB (1%)
Text #1
ID : 4608 (0x1200)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144
Text #2
ID : 4609 (0x1201)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144
Making the MKV file with a forced 1920*1080 solution solved the problem, and it plays fine. HP@4.2 format is not an issue.
What remains is, why HB uses a wrong aspect ratio. The HB scan log correctly identifies the 1.78 ratio, but it tries to use 1.74 (1920*1104). Any thoughts? Googling around reveals a few (old) threads with some aspect ratio problems, but they all end rather nasty 
Cocovanna
Two suggestions: Try a Nightly Build (if you aren’t already)
– Post on the HandBrake forum. They’re very good over there, especially if you remember to follow the rules and attach ALL of the required LOGS. :)
The Handbrake forum, as Tony says, is probably a better bet, but what I think happens is that HB scans the file as it’s adding it… if it finds “unused” pixels at the top or bottom, or at the sides, then it chucks them out, and tries to re-scale the image back to the given size (or as close as it can get). And it probably knows that it has to cut the width off at 1920.
That’s probably why you’re ending up with odd sizes.
I know with DVDs it often wants to change a 720x480 source file into something like 640*496, depending on what gets auto-cropped and what the specified AR is.
You could probably manually undo the cropping and get the output size back to 1920x1080.
…Right, RG, and it often does a crappy job of that “LetterBox/Pillar Box” detection.
I have a few DVDs that have Extras that were SHOT in 16:9, but DISPLAY at 4:3 (thus, on my widescreen, it’s both LB’d and PB’d.
Handbrake tries to do me a favor and crops it. The MKV then fills the entire screen.
Problem is, a minute or so into those scenes, the producers put a Text Title at the bottom, and HB has cropped it out.
So, it’s not that those pixels are entirely unused, they’re just unused in the very small sampling it examines when deciding what to do.
You CAN turn off that feature, as you discovered, by altering the Anamorphic Settings.
RG:It detects the size correctly (and shows it) during scan, but it insists on converting the 1080 pixels in height to 1104 … if I try to reduce the 1104 to 1080, it lowers the 1920 accordingly, trying to keep a (wrong) aspect ratio. All the 1104 pixels holds (the same) picture information as the 1080 original ones, this is easy to see visually. I can fix it manually, just thinks it is weird. It seems that it does it a bit randomly, some episodes are changed to 1072, probably due to the same cause.
Tony: Im not member at the HB forum, and I’ll need a bigger problem to join yet another forum … especially when searching seems to indicate that the problem is old and reported/rejected earlier. And yes, I am using a pretty new nightly. I’ll keep an eye on the problem for the following BD rips and might try a reencode of this file at a later time, HandBrake IS making a lot of changes for BD currently.Tnx anyway.
Cocovanna
