After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 782697 - h265parse: Trailing zeroes in generated codec_data
h265parse: Trailing zeroes in generated codec_data
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.12.0
Other Linux
: Normal normal
: 1.12.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-05-16 15:18 UTC by Florian Zwoch
Modified: 2017-05-29 07:56 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Gstreamer 1.12 (15.62 KB, text/plain)
2017-05-16 15:18 UTC, Florian Zwoch
  Details
GStreamer 1.10 (7.98 KB, text/plain)
2017-05-16 15:19 UTC, Florian Zwoch
  Details
MP4Box Info (2.10 KB, text/plain)
2017-05-16 15:19 UTC, Florian Zwoch
  Details
Test file (527.15 KB, application/octet-stream)
2017-05-18 07:53 UTC, Florian Zwoch
  Details
discoverer: Consider parent/child streams the same if they have caps with the same name (2.10 KB, patch)
2017-05-18 08:23 UTC, Sebastian Dröge (slomo)
rejected Details | Review

Description Florian Zwoch 2017-05-16 15:18:52 UTC
Created attachment 351977 [details]
Gstreamer 1.12

GstDiscoverer lists an unexpected track count for my MP4 file. Unfortunately I could not get clearance to attach the MP4 file - else I would have.

The MP4 file was created with MP4Box:

MP4Box -add "stream.265":forcesync -add "stream2.265":forcesync out.mp4

The HEVC streams are Bluray compatible streams.

I will attach 3 logs:

a) gst-discoverer-1.0 -v with GStreamer 1.12
b) gst-discoverer-1.0 -v with GStreamer 1.10
c) The output of MP4Box -info out.mp4

As far as I can tell GstDiscoverer reports 4 visual tracks although only 2 tracks should be found.

I can actually use qtdemux and display both tracks (I haven't checked if it exposes more than 2 tracks though).

I may be able to add an MP4 file if I can get access to some bitstreams that may be distributed.
Comment 1 Florian Zwoch 2017-05-16 15:19:16 UTC
Created attachment 351978 [details]
GStreamer 1.10
Comment 2 Florian Zwoch 2017-05-16 15:19:35 UTC
Created attachment 351979 [details]
MP4Box Info
Comment 3 Sebastian Dröge (slomo) 2017-05-17 07:36:30 UTC
Can you just create a stream with "gst-launch-1.0 videotestsrc num-buffers=1000 ! x265enc ! filesink location=raw.h256" and pack that into a MP4? Having a sample file would in any case be useful, or if you could "git bisect" between 1.10 and 1.12 to find the offending commit.
Comment 4 Sebastian Dröge (slomo) 2017-05-17 07:36:57 UTC
That commit would be most likely in gst-plugins-good/gst/isomp4 btw
Comment 5 Florian Zwoch 2017-05-18 07:53:52 UTC
Created attachment 352073 [details]
Test file

Here is a small test file. Not sure if I'm the right guy to spot errors in the code in that area.. :-)

Bitstream generated with:

"gst-launch-1.0 videotestsrc num-buffers=100 ! x265enc ! h265parse ! video/x-h265, format=bytestream ! filesink location=out.265"

MP4 file generated with:
"MP4Box -add "out.265":forcesync out.mp4"


Here are the differences between the version from a simple discoverer call. The 1.12 version shows another sub track(?) for some reason.

1.12:
Analyzing file:///c:/users/fzwoc/Desktop/out.mp4
Done discovering file:///c:/users/fzwoc/Desktop/out.mp4

Topology:
  container: Quicktime
    video: H.265 (Main Profile)
      video: H.265 (Main Profile) <-- ??

Properties:
  Duration: 0:00:03.333333333
  Seekable: yes
  Tags:
      video codec: H.265 / HEVC
      bitrate: 1290674
      datetime: 2017-05-18T07:27:24Z
      container format: ISO MP4/M4A




1.10:
Analyzing file:///home/fzwoch/code/VisionPlay/out.mp4
Done discovering file:///home/fzwoch/code/VisionPlay/out.mp4

Topology:
container: Quicktime
  video: H.265 (Main Profile)

Properties:
Duration: 0:00:03.333333333
Seekable: yes
Tags: 
    video codec: H.265 / HEVC
    bitrate: 1290674
    datetime: 2017-05-18T07:27:24Z
    container format: ISO MP4/M4A




MP4Box -info:
	* Movie Info *
		Timescale 600 - Duration 00:00:03.333
		1 track(s)
		Fragmented File: no
		File suitable for progressive download (moov before mdat)
		File Brand iso4 - version 1
		Created: GMT Thu May 18 07:27:24 2017
		Modified: GMT Thu May 18 07:27:24 2017

	File has no MPEG4 IOD/OD

	Track # 1 Info - TrackID 1 - TimeScale 30 - Media Duration 00:00:03.333
	Track has 1 edit lists: track duration is 00:00:03.333
	Media Info: Language "und (und)" - Type "vide:hvc1" - 100 samples
	Visual Track layout: x=0 y=0 width=320 height=240
	MPEG-4 Config: Visual Stream - ObjectTypeIndication 0x23
	HEVC Video - Visual Size 320 x 240
		HEVC Info: Profile Main @ Level 2.1 - Chroma Format 1
		NAL Unit length bits: 32 - general profile compatibility 0x60000000
		Parameter Sets: 1 VPS 1 SPS 1 PPS 
		SPS resolution 320x240 - Pixel Aspect Ratio 1:1 - Indicated track size 320 x 240
		Bit Depth luma 8 - Chroma 8 - 1 temporal layers
		VPS#1 hash: F13C834A71EF1DB55ED73D7323EB4828D1D872F4
		SPS#1 hash: 343144344C9BD4477C6A223D5927513754E92722
		PPS#1 hash: 476CC254A14C7C38F1EC443B8C1E3E48B9736FDF

	Self-synchronized
		RFC6381 Codec Parameters: hvc1.1.6.L63.90
		Average GOP length: 100 samples
Comment 6 Sebastian Dröge (slomo) 2017-05-18 08:16:52 UTC
(In reply to Florian Zwoch from comment #5)
> Topology:
>   container: Quicktime
>     video: H.265 (Main Profile)
>       video: H.265 (Main Profile) <-- ??

Ah now I understand your problem. Note how the second "video:" line is indented, it's not another stream but a "substream" with more information.

This is still a bug in gst-discoverer, in this specific case it should've filtered out the "substream" as it's actually the same stream. Problem here is that:

1) gst-discoverer does not filter out enough fields to consider streams the same
2) h265parse appends a couple of 0 bytes to the codec_data for some unknown reason

Both should be fixed
Comment 7 Sebastian Dröge (slomo) 2017-05-18 08:23:07 UTC
Created attachment 352076 [details] [review]
discoverer: Consider parent/child streams the same if they have caps with the same name

Child streams could have more accurate width/height or various other
information added. If they have the same name, they are likely to be the
same streams.
Comment 8 Sebastian Dröge (slomo) 2017-05-18 08:43:25 UTC
h265parse part is fixed with this:

commit eb1f1ff0a588fe1a0ebde908a9a4a7d9585581cf
Author: Sebastian Dröge <sebastian@centricular.com>
Date:   Thu May 18 11:42:17 2017 +0300

    h265parse: Fix calculation of codec_data buffer size
Comment 9 Sebastian Dröge (slomo) 2017-05-18 10:15:14 UTC
Comment on attachment 352076 [details] [review]
discoverer: Consider parent/child streams the same if they have caps with the same name

Unfortunately not correct: video/mpeg,systemstream=true / false distinguishes between container and elementary stream.