Handbrake: HB can't open certain file

Created on 27 May 2020 · 8Comments · Source: HandBrake/HandBrake

Problem description:

I have a file I can't open with HB. I tried to remux it to MKV/MP4 using ffmpeg or mkvmerge first, didn't help.

The only thing uncommon about this file I can think of is that it has a delay of ~9s between audio and video (audio first).

The file is provided:

https://www.dropbox.com/sh/08j616fgqml8ubw/AAAhHgzAKc8m30AkhQrPbcm7a?dl=0

HandBrake version (e.g., 1.3.0):

Nightly 20200523123425-b652a7e1b-master (2020052301)

Operating system and version (e.g., Ubuntu 19.10, macOS 10.15 Catalina, Windows 10 1909):

Win7x64

Error message text and/or screenshot:

HandBrake Activity Log:

An Activity Log is required for support. Please read https://handbrake.fr/docs/en/latest/help/activity-log.html for more information.

~~~
HandBrake Nightly 20200523123425-b652a7e1b-master (2020052301)
OS: Microsoft Windows NT 6.1.7601 Service Pack 1
CPU: Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz
Ram: 16283 MB,
GPU Information:
Intel(R) HD Graphics 4600 - 10.18.14.5074
NVIDIA GeForce GTX 1050 - 26.21.14.4587
Screen: 1920x1080
Temp Dir: C:\Users\Administrator\AppData\Local\Temp\
Install Dir: C:\Program Files\HandBrake Nightly
Data Dir: C:\Users\Administrator\AppData\Roaming\HandBrake\Nightly

[05:20:08] Compile-time hardening features are enabled
[05:20:08] Nvenc version 10.0
[05:20:08] Nvenc version 10.0
[05:20:09] Nvenc version 10.0
[05:20:09] Nvenc version 10.0
[05:20:12] hb_init: starting libhb thread

# Starting Scan ...

[05:20:12] CPU: Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz
[05:20:12] - Intel microarchitecture Haswell
[05:20:12] - logical processor count: 4
[05:20:12] Intel Quick Sync Video support: yes
[05:20:12] - Intel Media SDK hardware: API 1.17 (minimum: 1.3)
[05:20:12] - H.264 encoder: yes
[05:20:12] - preferred implementation: hardware (any) via D3D11
[05:20:12] - capabilities (hardware): breftype vsinfo opt1 opt2+mbbrc+extbrc+trellis+ib_adapt+nmpslice
[05:20:12] - H.265 encoder: no
[05:20:12] hb_scan: path=D:\cut2.mp4, title_index=0
udfread ERROR: ECMA 167 Volume Recognition failed
src/libbluray/disc/disc.c:323: failed opening UDF image D:\cut2.mp4
src/libbluray/disc/disc.c:424: error opening file BDMV\index.bdmv
src/libbluray/disc/disc.c:424: error opening file BDMV\BACKUP\index.bdmv
src/libbluray/bluray.c:2585: nav_get_title_list(D:\cut2.mp4) failed
[05:20:12] bd: not a bd - trying as a stream/file instead
libdvdnav: Using dvdnav version 6.0.1
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
[05:20:12] dvd: not a dvd - trying as a stream/file instead
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'D:\cut2.mp4':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf58.42.102
Duration: 00:00:20.01, start: 0.000000, bitrate: 4225 kb/s
Stream #0:0(und): Video: h264 (avc1 / 0x31637661), none, 1920x1080, 7007 kb/s, SAR 1:1 DAR 16:9, 30.06 fps, 29.97 tbr, 16k tbn, 32k tbc (default)
Metadata:
handler_name : VideoHandler
Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 256 kb/s (default)
Metadata:
handler_name : SoundHandler
[05:20:12] ffmpeg_title_scan: Unsupported color space
[05:20:12] scan: decoding previews for title 1
No video decoder set!
[05:20:12] scan: Too few previews (0), trying harder
[05:20:12] scan: decoding previews for title 1
[05:20:12] libhb: scan thread found 0 valid title(s)

# Processing Scan Information ...

# Scan Finished ...

~~~

Enhancement

Source

fireattack

Most helpful comment

The video is being rejected in stream.c before we've even attempted to generate previews. I think this is probably the wrong place to do this. Ideally we should just allow it to continue and if the pix_fmt is unsupported, we'll get no previews.

The commit message where that bit of code was added doesn't say exactly why it was added (it's my commit, but it's 10 years old and I can't recall), but I'm thinking it may have had something to do with files that had more than one "video" stream. It may have been an attempt to weed out some extra stream that wasn't primary video.

So my thought is we just remove that check for now. If some other problem related to it re-appears, we re-fix it in a better way. E.g. one better way would be to allow the stream with unsupported pix_fmt to be added, but then replace it if another video stream is encountered that has a supported pix_fmt.

jstebbins on 28 May 2020

👍2 🚀1 🎉1

All 8 comments

Probably this bug: https://trac.ffmpeg.org/ticket/6375 as I noticed I can't even transcode it with ffmpeg unless supplying -max_muxing_queue_size 9999.

fireattack on 27 May 2020

[05:20:12] ffmpeg_title_scan: Unsupported color space

This means that handbrake cannot find a decoder that will work with this source. There are other tickets that have popped up over the years that have this problem, going as far back as #315 in 2016, and forum messages as far back as 2011.

What is the source of the video?

woodstockathbf on 28 May 2020

The problem should be the missing color space, which is set to none insted of yuv420p or so. 🤔
Seems like the (broken) source is the problem.

Dendraspis on 28 May 2020

[05:20:12] ffmpeg_title_scan: Unsupported color space

This means that handbrake cannot find a decoder that will work with this source. There are other tickets that have popped up over the years that have this problem, going as far back as #315 in 2016, and forum messages as far back as 2011.

What is the source of the video?

I downloaded it from some online video website.

fireattack on 28 May 2020

I saw that warning, but it _can_ be decoded by ffmpeg CLI (the lib we're using here) as soon as you use -max_muxing_queue_size 9999 as mentioned above. So I assume it can tolerate None (assume yuv420p?) and the cause is likely due to default queue size being too small.

It is different from #315, which actually uses a entirely different colorspace xyz12le, which Libav back then simply didn't support.

(Above is just my thinking process and guesses.)

fireattack on 28 May 2020

OK, after some testing I believe both are correct.

It is indeed caused by "no colorspace", but the reason FFMPEG cannot detect colorspace is exactly because it doesn't have video for the first 8s (audio only).

I increased the analyzeduration to 10s (10m microseconds) in ffprobe by using the following commands:

ffprobe cut2.mp4 -v 99 -analyzeduration 10000000

It then can detect colorspace just fine:

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cut2.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf58.42.102
  Duration: 00:00:20.01, start: 0.000000, bitrate: 4225 kb/s
    Stream #0:0(und), 1, 1/16000: Video: h264 (High), 1 reference frame (avc1 / 0x31637661), yuv420p(left), 1920x1080 (1920x1088) [SAR 1:1 DAR 16:9], 0/1, 7007 kb/s, 30.06 fps, 29.97 tbr, 16k tbn, 59.94 tbc (default)
    Metadata:
      handler_name    : VideoHandler
    Stream #0:1(und), 410, 1/48000: Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 256 kb/s (default)
    Metadata:
      handler_name    : SoundHandler

And that's also why -max_muxing_queue_size 9999 works, since it has a similar mechanism.

fireattack on 28 May 2020

👍1

We've increased the analyze duration before. That said, 10 seconds is pretty long.

@jstebbins I wonder whether we could try once with a nominal analyze duration, and if no source found, make a second attempt with a much longer duration?