Opened 11 years ago

Closed 11 years ago

#1248 closed defect (invalid)

HM encoder crashes after encoding a few frames of 4K content (3840x2160)

Reported by: xinjun Owned by:
Priority: minor Milestone: HM-14.0
Component: HM Version: HM-13.0
Keywords: Cc: fbossen, ksuehring, davidf, jct-vc@…

Description

HM encoder (13.0) crashes after encoding a few frames of 4K content (3840x2160x30)
(Any 4k content should do, just set resolution to 3840x2160, see attached.)

############################################################

  • HM source code SVN:

​https://hevc.hhi.fraunhofer.de/svn/svn_HEVCSoftware/trunk

r3800 | bossen | 2014-01-22 08:53:58 -0800 (Wed, 22 Jan 2014) | 1 line

Change version number to 13.0

############################################################
-- built using HM_vc9.sln on Windows 7.

############################################################
--- Command line:
hm13.exe -c encoder_randomaccess_main.cfg -c Duck_qp28.cfg

  1. Duck_qp_28.cfg is attached.
  2. encoder_randomaccess_main.cfg is from SVN repository.
  3. encoder_lowdelay_P_main.cfg also crashes.

############################################################

crashes after encoding 9 frames (randomaccess) or 10 frames (lowdelay_P_main).

Attachments (1)

Duck_qp28.cfg​ (597 bytes) - added by xinjun 11 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 11 years ago by DefaultCC Plugin

  • Cc fbossen ksuehring davidf jct-vc@… added

Changed 11 years ago by xinjun

comment:2 Changed 11 years ago by davidf

Did previous versions work using this configuration?

If so, please provide a stack trace.

comment:3 Changed 11 years ago by xinjun

No, this is the first time I tried to encode 4k material.

I had been always using HM11, it didn't work for 4K encode settings.
So I tried HM13 too, but it still crashed.
(Btw, HM worked fine with same input file, if I config the input resolution to be 1920x1080 - instead of the real resolution 3840x2160.
I'm pretty sure it's not due to input file .)

I haven't tried any other versions.

comment:4 Changed 11 years ago by davidf

The usual cause of crashes with 4K is running out of memory. Please confirm if this is the case (usually indicated by an attempted null pointer dereference after an allocation).

comment:5 Changed 11 years ago by xinjun

Okay, I could do more tests to figure out where it crashes.
My PC has 16 GB of memory, I would think that should be enough for running more than a few frames?
(from my Memory usage graph, it's not using even quarter of the total memory)

Moreover, whether I ran two jobs at the same time, or I ran one job only, the crash took place at the same frame.
Had HM ever being tested for encoding 4K contents?

Perhaps I should build 64-bit application?

Last edited 11 years ago by xinjun (previous) (diff)

comment:6 Changed 11 years ago by davidf

If you have not built a 64-bit binary, the process is limited in the size of the virtual address space it can access (depending upon system, that can typically be between 2 GiB and some amount less than 4 GiB¹).

You will need to build a 64-bit binary in order to avoid this.

From experience, coding 4k is unlikely to work using HM using a 32-bit process.

¹ NB, on windows may be controlled to some extend at link time using the /LARGEADDRESSAWARE linker option.

comment:7 Changed 11 years ago by xinjun

I will try to build 64-bit application and report back. thanks

comment:8 Changed 11 years ago by xinjun

Confirmed that 64-bit application successfully encodes beyond a few frames.

Please close this issue, and perhaps a sentence or two can be added in software manual against 32-bit applications.

comment:9 Changed 11 years ago by davidf

  • Resolution set to invalid
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.

This list contains all users that will be notified about changes made to this ticket.

These roles will be notified: Reporter, Owner, Subscriber, Participant

  • David Flynn(Subscriber, Participant)
  • Frank Bossen(Subscriber)
  • jct-vc@…(Subscriber)
  • Jun Xin(Reporter, Participant)
  • karl.sharman@…(Always)
  • Karsten Suehring(Subscriber, Always)