HEVC muxing issue

[Selur]

Using the latest nightly I get the following when trying to multiplex:
MP4Box -par 1=1:1 -add "h:\Output\test.265"#video:fps=25 -brand hvc1 -new "H:\Output\muxed.mp4"
an H265 file, which was created using:
x265 --input - --output-depth 10 --y4m --profile main10 --no-high-tier --level-idc 5.2 --limit-modes --no-open-gop --lookahead-slices 0 --bitrate 1500 --crf-min 0.00 --crf-max 0.00 --cbqpoffs -2 --crqpoffs -2 --psy-rd 2.50 --rdoq-level 2 --psy-rdoq 15.00 --aq-mode 2 --cu-lossless --vbv-maxrate 60000 --vbv-bufsize 60000 --hrd --aud --repeat-headers --range limited --colorprim bt2020 --colormatrix bt2020nc --max-cll "1000,200" --output "H:\test.265"
MP4Box Output:

�[32mHEVC import - frame size 3840 x 2160 at 25.000 FPS
�[32mHEVC Import results: 101 samples (314 NALUs) - Slices: 2 I 24 P 74 B - 108 SEI - 2 IDR
�[0m�[32mStream uses forward prediction - stream CTS offset: 2 frames
�[0m
Error: Feature Not Supported

Uploaded the test.265 file to my Google Share

Had this issue with multiple files that were created using a similar command line.
(Tried this on Windows and Mac OS X Sierra)

[rbouqueau]

Your sample file works here:

HEVC import - frame size 3840 x 2160 at 25.000 FPS
HEVC Import results: 101 samples (314 NALUs) - Slices: 2 I 24 P 74 B - 108 SEI - 2 IDR
Stream uses forward prediction - stream CTS offset: 2 frames
Saving tmp.mp4: 0.500 secs Interleaving

Do you use the latest GPAC version?

[Selur]

I think so,.... using
MP4Box -version
Mac version gives me:

MP4Box - GPAC version 0.6.2-DEV-rev1133-gc77fdae-master

the one I use on Windows says:

MP4Box - GPAC version 0.6.2-DEV-rev1133-gc77fdae-ab-suite

side note: downloaded the Mac version from https://gpac.wp.mines-telecom.fr/downloads/gpac-nightly-builds/ and compiled the Windows version using https://github.com/jb-alvarado/media-autobuild_suite

[rbouqueau]

Oh my bad, I didn't use the same command-line as you did. I can reproduce.

The file is imported as hev1, not hvc1. You need hvc1 to use the -par option. Unfortunately changing the brand won't suffice as it doesn't change the signalling.

The file is imported as hev1 because a PPS with the same id but different is encountered. Did you try to contact the x265 dev? I know there is also another open issue about initial data being sent by the encoder being set at default values - this may be related.

Note to self:

/*if we get twice the same PPS put it in the bitstream and set array_completeness to 0 ...*/
...
ppss->array_completeness = 0;

then

		if (entry->hevc_config && hevc_cleanup_config(entry->hevc_config->config, operand_type))
			array_incomplete=1;

[Selur]

Haven't tried to contact the x264 devs since it seemed like a MP4Box bug (some files encoded with the same settings worked fine some didn't). :)

created an entry into their bug tracker: https://bitbucket.org/multicoreware/x265/issues/309

[rbouqueau]

Actually that's something within the stream that triggers this behaviour: MP4Box just can't use hvc1 because there is an id collision in the stream. It would be good to know why the encoder did this.

On our side, we could certainly add checks (more accurate error messages, detection of duplicates in case of same id use). Open to suggestions.

[Selur]

that's the first reply I got in the x265 bugtracker:

We use id 0 for the VPS, SPS, and PPSes that we generate. Are you recommending a change in this?

Since I'm not knowledgeable in this regard it would be cool if the GPAC and x265 team could hash this out. :)

[rbouqueau]

Thank you . I answered there: https://bitbucket.org/multicoreware/x265/issues/309/mp4box-incompatibility

[Selur]

@rbouqueau: thanks for that there's an update over at the x265 tracker would be nice if you could comment there again :)

[rbouqueau]

@Selur Thanks. IIUC you seem to report MP4Box crashes in this message: https://bitbucket.org/multicoreware/x265/issues/309/mp4box-incompatibility#comment-32974891
Would it be possible to share the corresponding crashes so that we fix that?

[Selur]

sorry, wrong word on my end, that's causing a confusion. it's the error I mentioned in the first post. :)

[rbouqueau]

I answered there. I would need the samples to understand what's going on. I understand that they make updates on the SPS with a same IDs, but it would be great for us to know what to do in this case (and a trailer 0 byte here doesn't look like an optimization but rather a bug). @Selur It may be important for the x265 maintainers to understand that it would make your life much more painful with certain use-cases if it randomly fails.

[ZmGorynych]

Is there any solution other than disabling PPS changes (as suggested in https://bitbucket.org/multicoreware/x265/issues/309 )?

[jeanlf]

one possibility could be to create a track with several hvc1 entries, but this might not be very well supported by most players. We currently don't have support for that in MP4Box but that shouldn't be too hard to patch

[rbouqueau]

Do we have one decoder/player that would support such streams?

[ZmGorynych]

Would hev1 work?

…

On Thu, May 18, 2017 at 04:13 jeanlf ***@***.***> wrote: one possibility could be to create a track with several hvc1 entries, but this might not be very well supported by most players. We currently don't have support for that in MP4Box but that shouldn't be too hard to patch — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#705 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAxMZUcVMtVpFWkgxt_SRL6o9h6okexWks5r6_2mgaJpZM4K9Itd> .

[jeanlf]

not for par rewrite, this is only supported for hvc1 tracks

[ZmGorynych]

@jeanlf, here is what the 14496-15 4th edition says:

Section 8.3.2

Parameter sets: A parameter set to be used in a picture must be sent prior to the sample containing that picture or in the sample for that picture. For a video stream that a particular sample entry applies to, the video parameter set, sequence parameter sets, and picture parameter sets, shall be stored only in the sample entry when the sample entry name is 'hvc1', and may be stored in the sample entry and the samples when the sample entry name is 'hev1'.
NOTE 1: Storing parameter sets in the sample entries of a video stream provides a simple and static way to supply parameter sets. Storing parameters in samples on the other hand is more complex but allows for more dynamism in the case of parameter set updates (a particular parameter set’s content is changed but using the same ID) and in the case of adding additional parameter sets. A decoder initializes with the parameter sets in the sample entry, and then updates using the parameter sets as they occur in the stream, starting from any sample marked as a sync sample. Such updating may replace parameter sets with a new definition using the same identifier. Each time the sample entry changes, the decoder re-initializes with the parameter sets included in the sample entry.

In my reading, in hev1 you can have different PPS's if they are stored in samples, and this is explicitly for the purpose of changing them dynamically throughout the stream.

[jeanlf]

sure - what I meant is using MP4Box -par only works for hvc1. We already support hev1 storage

[ZmGorynych]

@jeanlf : any command-line example for generating hev1?

[jeanlf]

use xps_inband switch (works for both avc and hevc):
MP4Box -add raw.hvc:xps_inband -new hev1.mp4

[ZmGorynych]

@jeanlf : Thanks! Works on my TV like a charm!
🥇