GNOME Bugzilla – Bug 782697
h265parse: Trailing zeroes in generated codec_data
Last modified: 2017-05-29 07:56:57 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.
Created attachment 351978 [details] GStreamer 1.10
Created attachment 351979 [details] MP4Box Info
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.
That commit would be most likely in gst-plugins-good/gst/isomp4 btw
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
(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
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.
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 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.