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 631313 - [h264parse] avc -> byte format conversion problem
[h264parse] avc -> byte format conversion problem
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
0.10.18
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-10-04 13:06 UTC by Steven
Modified: 2010-10-05 11:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Akiyo, x264, 320kbps, wrapped in .mkv (449.09 KB, video/x-matroska)
2010-10-04 13:06 UTC, Steven
Details

Description Steven 2010-10-04 13:06:18 UTC
Created attachment 171698 [details]
Akiyo, x264, 320kbps, wrapped in .mkv

The pipeline

gst-launch-0.10 filesrc location=z.mkv ! matroskademux ! h264parse output-format=byte ! filesink location=z.h264

generates the same file as

gst-launch-0.10 filesrc location=z.mkv ! matroskademux ! filesink location=z.h264

and neither play well with external viewers. The goal is to demux from matroska to H.264 NAL transport format.
Comment 1 Tim-Philipp Müller 2010-10-04 13:47:53 UTC
For me with git it outputs different things just fine, but decoding the resulting stream also doesn't work well for me:

$ gst-launch-0.10 souphttpsrc location='https://bugzilla.gnome.org/attachment.cgi?id=171698' ! matroskademux ! h264parse ! fakesink dump=true 2>&1 | grep ^00000000 | head -n 5
00000000 (0xe92037): 00 00 02 98 06 05 ff ff 94 dc 45 e9 bd e6 d9 48  ..........E....H
00000000 (0xe912ad): 00 00 01 0f 41 9a 01 02 36 21 0f 2c 0d f7 68 f1  ....A...6!.,..h.
00000000 (0xe913c6): 00 00 00 2b 01 9e 02 00 bc 84 3f 89 f7 47 3d b8  ...+......?..G=.
00000000 (0xe913fb): 00 00 00 22 01 9e 02 01 3c 84 3f 89 f7 47 3d c6  ..."....<.?..G=.
00000000 (0xe91427): 00 00 00 1b 01 9e 02 01 bc 84 3f 15 4b 15 37 a5  ..........?.K.7.

$ gst-launch-0.10 souphttpsrc location='https://bugzilla.gnome.org/attachment.cgi?id=171698' ! matroskademux ! h264parse output-format=byte ! fakesink dump=true 2>&1 | grep ^00000000 | head -n 5
00000000 (0x1e4db50): 00 00 00 01 06 05 ff ff 94 dc 45 e9 bd e6 d9 48  ..........E....H
00000000 (0x1e20cb0): 00 00 00 01 67 64 00 0d ac 34 e4 05 82 5a 10 00  ....gd...4...Z..
00000000 (0x1e320a0): 00 00 00 01 68 ef b2 c8 b0                       ....h....       
00000000 (0x1e4f8a0): 00 00 00 01 41 9a 01 02 36 21 0f 2c 0d f7 68 f1  ....A...6!.,..h.
00000000 (0x1e3e080): 00 00 00 01 01 9e 02 00 bc 84 3f 89 f7 47 3d b8  ..........?..G=.

ffmpeg/mplayer is complaining:


libavformat file format detected.
[h264 @ 0x280d3d0] non-existing PPS referenced
[h264 @ 0x280d3d0] non-existing PPS 0 referenced
[h264 @ 0x280d3d0] decode_slice_header error
[h264 @ 0x280d3d0] no frame!
[h264 @ 0x280d3d0] Missing reference picture
[h264 @ 0x280d3d0] decode_slice_header error
[h264 @ 0x280d3d0] concealing 396 DC, 396 AC, 396 MV errors
[h264 @ 0x281d230] max_analyze_duration reached
Comment 2 Mark Nauwelaerts 2010-10-05 11:47:19 UTC
The above problems are likely due to h264parse being reluctant to split packetized input into separate NALs, unless specifically requested to do so using split-packetized=true.   

In particular, using following pipeline (with recent git):
----
gst-launch-0.10 souphttpsrc
location='https://bugzilla.gnome.org/attachment.cgi?id=171698' ! matroskademux
! h264parse output-format=byte split-packetized=true ! filesink location=output.h264
----
leads to output.h264 which plays well using playbin2 and mplayer (give or take minor complaints).  The subsequent NALs consist of SEI, SPS, PPS, IDR-I, NIDR-P, etc, which is also fine.