Forum rules
An Activity Log is required for support requests. Please read How-to get an activity log? for details on how and why this should be provided.
Description of problem or question:
I have some Video recorded from a HikVision CCTV camera which handbrake will not open - They will however play in VLC
Steps to reproduce the problem (If Applicable):
Just try opening the file
HandBrake version (e.g., 1.0.0):
1.1.1 and 1.1.2
Operating system and version (e.g., Ubuntu 16.04 LTS, macOS 10.13 High Sierra, Windows 10 Creators Update):
macOS 10.13.6 High Sierra
Stream 0
Type Video
Video Resolution 3072 x 2048
Buffer dimensions 3072 x 2048
Frame Rate 20
Decoded Format Planar 4:2:0 YUV Full Scale
Orientation Top Left
Color Primaries ITU-R BT.709
Color transfer function ITU-R BT.709
Color space ITU-R BT.709 Range
Stream 1
Codec CVD subtitles (cvd)
Type Subtitle
Last edited by Anonymous on Thu Sep 13, 2018 6:33 pm, edited 1 time in total.
Reason:Logs in [code][/code] blocks please
[16:43:19] macgui: Handbrake Version: 20180909191723-09ed0b5-master (2018091301)
[16:43:19] hb_init: starting libhb thread
[16:43:19] hb_init: starting libhb thread
[16:43:41] macgui: trying to open a folder or file
[16:43:41] macgui: ScanCore scanning titles with a duration of 10 seconds or more
[16:43:41] CPU: Intel(R) Core(TM) i5-4260U CPU @ 1.40GHz
[16:43:41] - Intel microarchitecture Haswell
[16:43:41] - logical processor count: 4
[16:43:41] hb_scan: path=/Volumes/BitBucket3/Camera04_20180901092953_20180901100217_69474.mp4, title_index=0
udfread ERROR: ECMA 167 Volume Recognition failed
disc.c:323: failed opening UDF image /Volumes/BitBucket3/Camera04_20180901092953_20180901100217_69474.mp4
disc.c:424: error opening file BDMV/index.bdmv
disc.c:424: error opening file BDMV/BACKUP/index.bdmv
[16:43:41] bd: not a bd - trying as a stream/file instead
libdvdnav: Using dvdnav version 6.0.0
libdvdread: Encrypted DVD support unavailable.
libdvdread:DVDOpenFileUDF:UDFFindFile /VIDEO_TS/VIDEO_TS.IFO failed
libdvdread:DVDOpenFileUDF:UDFFindFile /VIDEO_TS/VIDEO_TS.BUP failed
libdvdread: Can't open file VIDEO_TS.IFO.
libdvdnav: vm: failed to read VIDEO_TS.IFO
[16:43:41] dvd: not a dvd - trying as a stream/file instead
[16:43:41] file is MPEG Program Stream
[16:43:41] Found program stream map
[16:43:41] Found program stream map
[16:43:41] Found program stream map
..........REPEATED LINES REMOVED ..........
[16:43:42] Found program stream map
[16:43:42] Probing 3 unknown streams
[16:43:43] Found the following streams
[16:43:43] Video Streams :
[16:43:43] Audio Streams :
[16:43:43] Subtitle Streams :
[16:43:43] Other Streams :
[16:43:43] 0xe0-0x0 type Unknown (0x24)
[16:43:43] 0xc0-0x0 type AC3/IGS (0x91)
[16:43:43] 0xbd-0x0 type Unknown (0x0)
[16:43:43] libhb: scan thread found 0 valid title(s)
[16:43:43] macgui: ScanCore scan done
Last edited by Anonymous on Thu Sep 13, 2018 6:32 pm, edited 1 time in total.
Reason:Logs in [code][/code] blocks please
This does look like it might be our bug in the MPEG demuxer. Assuming it is indeed, should be fixable, but could you provide a short sample (just a few seconds) source for us to test? You can use Dropbox or similar.
This is another case of our PS demux mistakenly recognizing an mp4 file as PS. I won't have time to do a deeper dive to see if there is anything we can do about it for a couple of weeks. But this should be added to a github issue so it doesn't get overlooked.
The file does not open in QuickTime Player on macOS 10.13.6. I'm not seeing anything of substance indicating it's an MP4 container aside from the file extension.
BradleyS wrote: ↑Mon Sep 24, 2018 4:35 pm
The file does not open in QuickTime Player on macOS 10.13.6. I'm not seeing anything of substance indicating it's an MP4 container aside from the file extension.
Ah, I just assumed it was that old problem again. Seems it is a mis-named PS file that we just fail to see any video stream in.
After a quick look, our PS demux doesn't support h.265. Some investigation into the proper stream type(s) and iframe recognition will be required to add support.
First, we don't recognize h.265 in PS streams. It's an omission that's pretty easily solved by enabling stream probing for any unidentified stream. Right now we only enable probing for specific streams that have ambiguous stream IDs.
Second, there's a bug in how we decode PS packets. This stream delivers partial frames in each PS packet. It breaks it down so far that the VPS, SPS, and PPS of the hevc stream are each delivered in their own individual PS packets. We are expecting these NAL units to all be in a single PS packet which causes us to fail to initialize the decoder.
FYI, we still don't parse keyframes for HEVC in PS (or TS). This causes errors in the log during preview generation since the decoder doesn't receive data starting at a clean keyframe after the seeks during scan. It will result in some unclean preview frames in some cases. For this particular source I got a few unreadable preview frames.