GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2022-11-10T09:21:09Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/862h264parse: inserts extra NALU AUDs2022-11-10T09:21:09ZAndreas Frischh264parse: inserts extra NALU AUDsIn a pipeline demuxing an flv stream into h264 byte-stream, an additional NAL Access unit delimiter 0x0000000109f0 is inserted before the already existing AUD 0x000000010910 for every packet.
Tested with GStreamer 1.18.5 and main (1.19....In a pipeline demuxing an flv stream into h264 byte-stream, an additional NAL Access unit delimiter 0x0000000109f0 is inserted before the already existing AUD 0x000000010910 for every packet.
Tested with GStreamer 1.18.5 and main (1.19.2.1)
`gst-launch-1.0 videotestsrc num-buffers=1 ! x264enc bitrate=1 ! flvmux ! flvdemux ! h264parse ! video/x-h264, stream-format=byte-stream ! fakesink dump=true`
results in:
`00000000 (0x7f2aa015c2d0): 00 00 00 01 09 f0 00 00 00 01 09 10 00 00 00 01 ................`
`gst-launch-1.0 videotestsrc num-buffers=1 ! x264enc bitrate=1 ! flvmux ! flvdemux ! h264parse ! video/x-h264 ! fakesink dump=true`
results in:
`00000000 (0x7f46ac0054e0): 00 00 00 02 09 10 00 00 00 1d 67 f4 00 0d 91 9b ..........g.....`
the problem persists when working with an flv file that was generated by ffmpeg, so i suspect the culprit to be in the flv demuxer, not the muxer.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/133h264parse: interlaced detection unreliable on rtsp streams (french TV, free.f...2021-09-24T14:32:25ZBugzilla Migration Userh264parse: interlaced detection unreliable on rtsp streams (french TV, free.fr multiposte)## Submitted by Yannick
**[Link to original bug (#724714)](https://bugzilla.gnome.org/show_bug.cgi?id=724714)**
## Description
Hi,
I'm using totem on Fedora 20 to watch french TV. This service is provided by my ISP using rtsp. ...## Submitted by Yannick
**[Link to original bug (#724714)](https://bugzilla.gnome.org/show_bug.cgi?id=724714)**
## Description
Hi,
I'm using totem on Fedora 20 to watch french TV. This service is provided by my ISP using rtsp.
The auto-deinterlace feature is unreliable : sometimes it works, sometimes it fails. IMHO those streams are always interlaced.
Here is an exemple :
http://sevmek.free.fr/gstreamer/rtspvideo2.gdphttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/852`h264parse` is unable to handle `nal`-aligned` byte-stream produced by `h264p...2021-10-28T15:36:57ZSimonas Kazlauskas`h264parse` is unable to handle `nal`-aligned` byte-stream produced by `h264parse`This issue originally arose from a test mp4 file which I am not able to share. Here's what I would see:
```
$ env GST_DEBUG=3 gst-launch-1.0 filesrc location=test.mp4 ! qtdemux ! h264parse ! 'video/x-h264,stream-format=byte-stream,align...This issue originally arose from a test mp4 file which I am not able to share. Here's what I would see:
```
$ env GST_DEBUG=3 gst-launch-1.0 filesrc location=test.mp4 ! qtdemux ! h264parse ! 'video/x-h264,stream-format=byte-stream,alignment=nal' ! h264parse ! avdec_h264 ! fakesink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
<SNIP SNIP SNIP SNIP, a bunch of messages repeating as below>
0:00:00.085977256 2276896 0x7fe6bc00ab60 ERROR libav :0:: No start code is found.
0:00:00.085985606 2276896 0x7fe6bc00ab60 ERROR libav :0:: Error splitting the input into NAL units.
0:00:00.085996246 2276896 0x1f05120 WARN libav gstavviddec.c:1954:gst_ffmpegviddec_handle_frame:<avdec_h264-0> Failed to send data for decoding
0:00:00.086054747 2276896 0x7fe6b0047500 ERROR libav :0:: No start code is found.
0:00:00.086064837 2276896 0x7fe6b0047500 ERROR libav :0:: Error splitting the input into NAL units.
0:00:00.086080947 2276896 0x1f05120 WARN libav gstavviddec.c:1954:gst_ffmpegviddec_handle_frame:<avdec_h264-0> Failed to send data for decoding
0:00:00.086107738 2276896 0x1f05120 WARN libav gstavviddec.c:1849:gst_ffmpegviddec_drain:<avdec_h264-0> send packet failed, could not drain decoder
0:00:00.086135488 2276896 0x1f05120 WARN videodecoder gstvideodecoder.c:1246:gst_video_decoder_sink_event_default:<avdec_h264-0> error: No valid frames decoded before end of stream
0:00:00.086143078 2276896 0x1f05120 WARN videodecoder gstvideodecoder.c:1246:gst_video_decoder_sink_event_default:<avdec_h264-0> error: no valid frames found
ERROR: from element /GstPipeline:pipeline0/avdec_h264:avdec_h264-0: No valid frames decoded before end of stream
Additional debug info:
../gst-libs/gst/video/gstvideodecoder.c(1246): gst_video_decoder_sink_event_default (): /GstPipeline:pipeline0/avdec_h264:avdec_h264-0:
no valid frames found
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...
```
And then the following pipeline would make gstreamer "work":
```
$ env GST_DEBUG=3 gst-launch-1.0 filesrc location=rtsp_short.mp4 ! qtdemux ! h264parse ! 'video/x-h264,stream-format=byte-stream,alignment=nal' ! h264parse ! 'video/x-h264,stream-format=byte-stream,alignment=au' ! avdec_h264 ! queue ! fakesink
Setting pipeline to PAUSED ...
0:00:00.035938709 2277666 0x8d7a00 WARN basesrc gstbasesrc.c:3688:gst_base_src_start_complete:<filesrc0> pad not activated yet
Pipeline is PREROLLING ...
0:00:00.036176032 2277666 0x81d520 WARN qtdemux qtdemux_types.c:244:qtdemux_type_get: unknown QuickTime node type pasp
0:00:00.036267034 2277666 0x81d520 WARN qtdemux qtdemux.c:3066:qtdemux_parse_trex:<qtdemux0> failed to find fragment defaults for stream 1
0:00:00.039668874 2277666 0x7f24c400ab60 ERROR libav :0:: no frame!
0:00:00.039730775 2277666 0x81d520 WARN h264parse gsth264parse.c:1490:gst_h264_parse_handle_frame:<h264parse1> broken/invalid nal Type: 6 SEI, Size: 50 will be dropped
0:00:00.040394174 2277666 0x7f24b8047500 ERROR libav :0:: no frame!
0:00:00.094741334 2277666 0x81d520 WARN libav gstavviddec.c:1954:gst_ffmpegviddec_handle_frame:<avdec_h264-0> Failed to send data for decoding
0:00:00.098506219 2277666 0x81d520 WARN libav gstavviddec.c:1954:gst_ffmpegviddec_handle_frame:<avdec_h264-0> Failed to send data for decoding
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
EOS received - stopping pipeline...
Execution ended after 0:00:01.262560158
Setting pipeline to NULL ...
Freeing pipeline ...
```
However the way it works is still non-ideal. In particular `h264parse` dropped some NAL units it did not understand, and there are still warnings and errors from `libav`, though non-fatal. In practice this seems to be just the first couple NALs missing, and that's it.
While I was not able to produce a shareable test file to reproduce the first problem, I managed to make a file which still readily reproduces the latter one. ![Test file](/uploads/eaa8ac7ab67f43bea2252626b2833a49/axis3.mp4).
```
$ env GST_DEBUG=3 gst-launch-1.0 filesrc location=/tmp/axis3.mp4 ! qtdemux ! h264parse ! 'video/x-h264,stream-format=byte-stream,alignment=nal' ! h264parse ! avdec_h264 ! fakesink
Setting pipeline to PAUSED ...
0:00:00.034832854 2284801 0x2141330 WARN basesrc gstbasesrc.c:3688:gst_base_src_start_complete:<filesrc0> pad not activated yet
Pipeline is PREROLLING ...
0:00:00.035142829 2284801 0x20868c0 WARN qtdemux qtdemux_types.c:244:qtdemux_type_get: unknown QuickTime node type pasp
0:00:00.035236890 2284801 0x20868c0 WARN qtdemux qtdemux.c:3066:qtdemux_parse_trex:<qtdemux0> failed to find fragment defaults for stream 1
0:00:00.039399953 2284801 0x7f956000ad60 ERROR libav :0:: no frame!
0:00:00.099272374 2284801 0x20868c0 WARN libav gstavviddec.c:1954:gst_ffmpegviddec_handle_frame:<avdec_h264-0> Failed to send data for decoding
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:02.074938961
Setting pipeline to NULL ...
Freeing pipeline ...
```
It works fine if there's no intermediate conversion to `video/x-h264,stream-format=byte-stream,alignment=nal`.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/503h264parse: keyframes marked as delta unit2019-06-16T00:33:39ZBugzilla Migration Userh264parse: keyframes marked as delta unit## Submitted by Nicola `@drakkan`
**[Link to original bug (#776582)](https://bugzilla.gnome.org/show_bug.cgi?id=776582)**
## Description
Created attachment 342575
file that show the issue
Please try this pipeline and observe ...## Submitted by Nicola `@drakkan`
**[Link to original bug (#776582)](https://bugzilla.gnome.org/show_bug.cgi?id=776582)**
## Description
Created attachment 342575
file that show the issue
Please try this pipeline and observe the output
gst-launch-1.0 -v filesrc location= test.gdp ! gdpdepay ! fakesink silent=false
you can see that all keyframes are correctly marked as such, for example:
42672 bytes, dts: none, pts: 0:00:01.667941354, duration: none, offset: -1, offset_end: -1, flags: 00000000
42667 bytes, dts: none, pts: 0:00:03.267941354, duration: none, offset: -1, offset_end: -1, flags: 00000000
now try to add h264parse:
gst-launch-1.0 -v filesrc location= test.gdp ! gdpdepay ! h264parse ! video/x-h264,stream-format=avc,alignment=au ! fakesink silent=false
42672 bytes, dts: 0:00:01.401274664, pts: 0:00:01.667941354, duration: 0:00:00.033333333, offset: 91068, offset_end: -1, flags: 00002000 delta-unit
42667 bytes, dts: 0:00:02.734607984, pts: 0:00:03.267941354, duration: 0:00:00.033333333, offset: 182136, offset_end: -1, flags: 00002000 delta-unit
keyframes are now marked as delta-unit!
**Attachment 342575**, "file that show the issue":
[test.gdp](/uploads/90d04056de09b8dcac93c9fdcf0735ad/test.gdp)
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/326h264parse: marks every buffer as header in dash stream2021-09-24T14:33:50ZBugzilla Migration Userh264parse: marks every buffer as header in dash stream## Submitted by Thiago Sousa Santos `@thiagossantos`
**[Link to original bug (#758419)](https://bugzilla.gnome.org/show_bug.cgi?id=758419)**
## Description
The stream: http://rdmedia.bbc.co.uk/dash/ondemand/bbb/2/client_manifest-sep...## Submitted by Thiago Sousa Santos `@thiagossantos`
**[Link to original bug (#758419)](https://bugzilla.gnome.org/show_bug.cgi?id=758419)**
## Description
The stream: http://rdmedia.bbc.co.uk/dash/ondemand/bbb/2/client_manifest-separate_init.mpd
*every* buffer coming out of h264parse is marked as a header.
Easily seen with a debug log 6 of playbin on that file and then grepping:
cat gst.log | grep "avdec_h264-0:sink>" |grep calling |less -RS
Note the flags at the end always contain 0x400https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/617h264parse: May break stream further rather then fixing it2021-09-24T14:35:51ZBugzilla Migration Userh264parse: May break stream further rather then fixing it## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#788595)](https://bugzilla.gnome.org/show_bug.cgi?id=788595)**
## Description
As found with this file in [bug 787795](https://bugzilla.gnome.org/show_bug.cgi?id=...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#788595)](https://bugzilla.gnome.org/show_bug.cgi?id=788595)**
## Description
As found with this file in [bug 787795](https://bugzilla.gnome.org/show_bug.cgi?id=787795), with the following FLV file:
https://bugzilla.gnome.org/attachment.cgi?id=360317
h264parse turns a slightly broken stream into an un-playable stream. As an example, the display video will be gray with the parser:
filesrc location=test.flv ! flvdemux ! h264parse ! avdec_h264 ! autovideosink
But looks fine without:
filesrc location=/tmp/test.flv ! flvdemux ! video/x-h264,alignment=au ! avdec_h264 ! autovideosinkhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1356h264parse: not correctly converting avc (alignment=au) to byte-stream (alignm...2023-06-13T17:11:50ZFlavio Correiah264parse: not correctly converting avc (alignment=au) to byte-stream (alignment=nal)I am using Gstreamer 1.14.5 to read a MPEG DASH stream **(H.264 stored in AVC format using AU alignment)** and convert it to elementary stream **(H.264 stored in byte-stream format using NAL alignment)**. However, the output is corrupt...I am using Gstreamer 1.14.5 to read a MPEG DASH stream **(H.264 stored in AVC format using AU alignment)** and convert it to elementary stream **(H.264 stored in byte-stream format using NAL alignment)**. However, the output is corrupted and the content can not be decoded correctly.
The follow errors are printed when we try to use mplayer to reproduce the output content:
**[h264 @ 0x7fc7012eb920]concealing 288 DC, 288 AC, 288 MV errors in P frame<br>**
**[h264 @ 0x7fc7012eb920]illegal short term buffer state detected**
This pipeline using a open MPEG DASH TEST MEDIA url can be used to reproduce the issue. (the url is from [BBC](http://rdmedia.bbc.co.uk/dash/ondemand/bbb/) )<br>
`gst-launch-1.0 -v souphttpsrc location=http://rdmedia.bbc.co.uk/dash/ondemand/bbb/2/client_manifest-common_init.mpd ! dashdemux name=demux multiqueue name=mq demux.video_00 ! mq.sink_1 mq.src_1 ! qtdemux ! h264parse ! video/x-h264,stream-format=byte-stream,alignment=nal ! filesink location=/tmp/video.h264`
I am using the MPlayer 1.3.0 to validate the video.h264 output but the gstreamer can be used too with the follow command:
`gst-launch-1.0 playbin uri=file:///tmp/video.h264`
I tested using Gstreamer 1.16 and it has the same issuehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/190h264parse: not correctly parsing or passing through avc2021-09-24T14:32:53ZBugzilla Migration Userh264parse: not correctly parsing or passing through avc## Submitted by Semen Belozorov
**[Link to original bug (#740118)](https://bugzilla.gnome.org/show_bug.cgi?id=740118)**
## Description
I have ip camera that sends the h264 stream over rtsp. When I try to display this stream using GS...## Submitted by Semen Belozorov
**[Link to original bug (#740118)](https://bugzilla.gnome.org/show_bug.cgi?id=740118)**
## Description
I have ip camera that sends the h264 stream over rtsp. When I try to display this stream using GStreamer 1.4.4, i get a broken picture.
Problem appears when using the following simple pipeline:
rtspsrc location=rtsp://10.0.6.189/mpeg4 protocols=tcp ! rtph264depay ! h264parse ! avdec_h264 ! videoconvert ! autovideosink
I can temporary get a correct picture, if I remove h264parse from the pipeline. Also, I can temporary get a correct picture if I use a GStreamer SDK 0.10. But in both cases, the picture may break later.
I found that the difference in behavior occurred after applying the following commit:
Revision: a41e8698b1ae62b18fd2449dfcb7c1b9d39d02b9
Author: Matej Knopp <matej.knopp@gmail.com>
Date: 08.09.2013 1:09:31
Message:
h264parse: don't update src caps if only codec_data differs
https://bugzilla.gnome.org/show_bug.cgi?id=705333
----
Modified: gst/videoparsers/gsth264parse.c
When I build the videoparsers in the state before applying this commit, I get the same behavior as in the case with a GStreamer SDK 0.10. But after some time the picture is still broke.
I recorded a part of the stream on which the picture is often broken. Sorry, it took so long. I've put it there:
https://drive.google.com/file/d/0Bw5nWXOdi4FybXpPMmVlQWsyVWs/view?usp=sharing
To reproduce the problem can be used the following pipeline:
gst-launch-1.0 filesrc location="CH9Hstream00002.gdp" ! gdpdepay ! rtph264depay ! avdec_h264 ! videoconvert ! autovideosinkhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/104h264parse: Only resends SPS/PPS periodically on IDR streams2023-07-06T11:01:45ZBugzilla Migration Userh264parse: Only resends SPS/PPS periodically on IDR streams## Submitted by lor..@..il.com
**[Link to original bug (#705030)](https://bugzilla.gnome.org/show_bug.cgi?id=705030)**
## Description
Created attachment 250309
GST_DEBUG=h264parse:6
I have the following pipeline:
gst-la...## Submitted by lor..@..il.com
**[Link to original bug (#705030)](https://bugzilla.gnome.org/show_bug.cgi?id=705030)**
## Description
Created attachment 250309
GST_DEBUG=h264parse:6
I have the following pipeline:
gst-launch-1.0 mpegtsmux name=mux ! tcpserversink host=192.168.1.103 port=5005 filesrc location=./netbeans/mpeg2.ts ! tsdemux name=demux demux. ! queue ! mpegvideoparse ! omxmpeg2videodec ! omxh264enc ! h264parse config-interval=1 ! mux. demux. ! queue ! mpegaudioparse ! mux.
Naturally, I expect that SPS/PPS packets are being sent each second so that when clients are connected they can start rendering video, unfortunately however this is not happening. I've attached a log of h264parse.
**Attachment 250309**, "GST_DEBUG=h264parse:6":
[h264parse.log](/uploads/76bce830db5f02113c560f745f279b1f/h264parse.log)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/166h264parse: output frames with no pts causes jerky rendering2021-09-24T14:32:41ZBugzilla Migration Userh264parse: output frames with no pts causes jerky rendering## Submitted by Aurélien Zanelli
**[Link to original bug (#734124)](https://bugzilla.gnome.org/show_bug.cgi?id=734124)**
## Description
Playing a specific ts file using this kind of pipeline:
gst-launch-1.0 filesrc location=1seg.t...## Submitted by Aurélien Zanelli
**[Link to original bug (#734124)](https://bugzilla.gnome.org/show_bug.cgi?id=734124)**
## Description
Playing a specific ts file using this kind of pipeline:
gst-launch-1.0 filesrc location=1seg.ts ! tsdemux program-number=23992 ! h264parse ! video/x-h264,stream-format=byte-stream,alignment=au ! avdec_h264 ! autovideosink
causes the rendering to be jerky.
The test file can be downloaded here: http://www.darkosphere.fr/tmp/gstreamer/1seg.ts
I think it could be caused by the h264parse element sending frame to decoder without pts.
Here is what I understand about the issue:
I notice that h264parse, in this case, rely on timestamp provided by upstream, ie tsdemux. But buffers pushed by tsdemux element can contain more than one AU, so sone of them will be pushed with a non valid PTS causing decoder to be confused.
Currently, I wrote an ugly ugly ugly hack (and pretty unclear) which slightly improve the rendering. My approach was to try to interpolate PTS using timing info through using gst_h264_parse_get_timestamp() in pre_push_frame().
What do you think about this issue, do you have better ideas ?
P.S: This issue can be a duplicate of [bug 659489](https://bugzilla.gnome.org/show_bug.cgi?id=659489), but I'm not sure.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/961h264parse: Possibly uncleared "multiview-mode" and "multiview-flags"2021-09-24T14:37:18ZSeungha Yangseungha@centricular.comh264parse: Possibly uncleared "multiview-mode" and "multiview-flags"Follow up of https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/merge_requests/308#note_156190
Frame packing arrange (FPA) SEI message informs multiview related information. Depending on parsed values from the SEI message, its per...Follow up of https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/merge_requests/308#note_156190
Frame packing arrange (FPA) SEI message informs multiview related information. Depending on parsed values from the SEI message, its persistence scope can vary. Meanwhile, we are clearing that information (when upstream didn't provide that via caps) per
1) sink caps was changed
2) new FPA has frame_packing_cancel_flag equal to one.
In spec, however, its persistent scope is dependent on `frame_packing_arrangement_repetition_period` value (which was not handled until now).
When `frame_packing_arrangement_repetition_period` equal to
1) `zero` then the FPA should be applied to the current frame only
2) `one` then the FPA SEI message persists
2-1) in that corresponding coded video sequence (i.e., GOP)
2-2) or new FPA with same FPA id (with PoC condition)
3) `> one` then
3-1) in that corresponding coded video sequence (i.e., GOP)
3-2) or new FPA with same FPA id (with PoC condition and something more..)
Note that `frame_packing_arrangement_repetition_period > 1` means another FPA should exist in that bitstream in the POC range of `(currentPoc, currentPoc + frame_packing_arrangement_repetition_period)`
That means, it should be cleared at least per GOP in theory.
CC: @slomohttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3254h264parse regression - fails to output any frames2024-01-30T02:05:31ZJan Schmidth264parse regression - fails to output any framesI have found an MPEG-TS file that plays in 1.22.8, VLC, ffmpeg etc, but fails to play in git main. Reverting !5741 and !5862 makes it work again.I have found an MPEG-TS file that plays in 1.22.8, VLC, ffmpeg etc, but fails to play in git main. Reverting !5741 and !5862 makes it work again.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/364h264parse removes padding from byte streams2021-09-24T14:34:11ZBugzilla Migration Userh264parse removes padding from byte streams## Submitted by Georg Lippitsch
**[Link to original bug (#764372)](https://bugzilla.gnome.org/show_bug.cgi?id=764372)**
## Description
When using h264parse element without a conversion (bytestream to bytestream), it removes padding ...## Submitted by Georg Lippitsch
**[Link to original bug (#764372)](https://bugzilla.gnome.org/show_bug.cgi?id=764372)**
## Description
When using h264parse element without a conversion (bytestream to bytestream), it removes padding bytes from the original h264 stream. Producing a real constant bitrate is then not possible anymore.
This can be reproduced with the following command line (you need 10Bit libx264):
# gst-launch-1.0 videotestsrc ! video/x-raw,width=1920,height=1080,format=I422_10LE,framerate=25/1 ! x264enc trellis=false option-string=avcintra-class=100 ! video/x-h264,stream-format=byte-stream ! h264parse ! mpegtsmux ! filesink location=test.ts
Every frame should then have exactly 568832 bytes. But checking the file test.ts with ffprobe gives different frame sizes for every frame. The frames sizes can be checked with:
# ffprobe -show_frames test.ts | grep pkt_size
Removing the "h264parse" element from the above pipeline and checking the frame sizes gives the expected size of 568832 bytes for every frame.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/34[h264parse] report creation date/time via GST_TAG_DATE_TIME2021-09-24T14:31:51ZBugzilla Migration User[h264parse] report creation date/time via GST_TAG_DATE_TIME## Submitted by Adam Dingle
**[Link to original bug (#642911)](https://bugzilla.gnome.org/show_bug.cgi?id=642911)**
## Description
GStreamer cannot currently report the creation/date of a MPEG TS video via a GST_TAG_DATE_TIME tag. ...## Submitted by Adam Dingle
**[Link to original bug (#642911)](https://bugzilla.gnome.org/show_bug.cgi?id=642911)**
## Description
GStreamer cannot currently report the creation/date of a MPEG TS video via a GST_TAG_DATE_TIME tag. It would be nice to have this capability.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/240h264parser/h264parse: Handle trailing 0s in NALU2021-09-24T14:33:13ZBugzilla Migration Userh264parser/h264parse: Handle trailing 0s in NALU## Submitted by Edward Hervey `@bilboed`
**[Link to original bug (#747850)](https://bugzilla.gnome.org/show_bug.cgi?id=747850)**
## Description
the H264 spec allows to have leading/traling zeros in byte stream
The problem is th...## Submitted by Edward Hervey `@bilboed`
**[Link to original bug (#747850)](https://bugzilla.gnome.org/show_bug.cgi?id=747850)**
## Description
the H264 spec allows to have leading/traling zeros in byte stream
The problem is that we don't know about it, and therefore we iterating over
NALU we are never guaranteed to end at the next NALU start code, but instead
on potentially trailing zero bytes
This would cause h264parse to tell baseparse to skip those few bytes, resulting
in the next buffer being a DISCONT one ... whereas it's not.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/87h264parser: Parse the cropping-rectangle separately.2021-09-24T14:32:07ZBugzilla Migration Userh264parser: Parse the cropping-rectangle separately.## Submitted by Sreerenj Balachandran `@sree`
**[Link to original bug (#694068)](https://bugzilla.gnome.org/show_bug.cgi?id=694068)**
## Description
Created attachment 236561
h264parser: Parse the cropping-rectangle separately.
...## Submitted by Sreerenj Balachandran `@sree`
**[Link to original bug (#694068)](https://bugzilla.gnome.org/show_bug.cgi?id=694068)**
## Description
Created attachment 236561
h264parser: Parse the cropping-rectangle separately.
The h264parser should parse the cropping rectangle separately. Because we have to pass the cropping rectangle to the renderer instead of using the cropped-values for decoding.Which means the width and height of SPS header will be un-cropped dimensions.
example case: many of the 1920x1088 samples of h264 have 8 padding lines to make the height as a multiple of 16. The actual picture dimension will be 1920x1080.
**Patch 236561**, "h264parser: Parse the cropping-rectangle separately.":
[0001-h264parser-Parse-the-cropping-rectangle-separately.patch](/uploads/0bb9e99f870fdb25bb0adcf7f295d71b/0001-h264parser-Parse-the-cropping-rectangle-separately.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/791h264parser: Should add a "unsupported" return value2021-09-24T14:36:43ZBugzilla Migration Userh264parser: Should add a "unsupported" return value## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#797217)](https://bugzilla.gnome.org/show_bug.cgi?id=797217)**
## Description
Currently, our parser will return "broken data" whenever an unsupported type is met...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#797217)](https://bugzilla.gnome.org/show_bug.cgi?id=797217)**
## Description
Currently, our parser will return "broken data" whenever an unsupported type is met. In some cases this is the correct thing to do, as it's forbidden by the spec, but in other case, this leads to data being dropped as if it was broken.
My suggestion would be to introduce an "unsupported" return value. This way, parser element can simply pass-through these NALs, as they are not proven to be invalid. This applies to non MVC slice entension types, for which we have a hack in h264parse element to avoid dropping.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/307h264parse: sets incomplete srccaps first2021-09-24T14:33:44ZBugzilla Migration Userh264parse: sets incomplete srccaps first## Submitted by Maroš Ondrášek
**[Link to original bug (#755885)](https://bugzilla.gnome.org/show_bug.cgi?id=755885)**
## Description
Created attachment 312435
h264parse log 1.5.1 and 1.6.0 comparison
I noticed changed behavi...## Submitted by Maroš Ondrášek
**[Link to original bug (#755885)](https://bugzilla.gnome.org/show_bug.cgi?id=755885)**
## Description
Created attachment 312435
h264parse log 1.5.1 and 1.6.0 comparison
I noticed changed behaviour of h264parse from 1.5.1 to 1.6.0:
testing pipeline:
GST_DEBUG_NO_COLOR=1 GST_DEBUG=basesink:5,h264parse:5 gst-launch-1.0 souphttpsrc location='http://f24hls-i.akamaihd.net/hls/live/221192/F24_FR_LO_HLS/master_900.m3u8' ! hlsdemux ! queue ! tsdemux ! h264parse ! fakesink
1.5.1:
received one caps event with complete caps, before rendering starts
gstbasesink.c:3170:gst_base_sink_event:`<fakesink0>` received event 0x7f2b54014c00 caps event: 0x7f2b54014c00, time 99:99:99.999999999, seq-num 69, GstEventCaps, caps=(GstCaps)"video/x-h264\,\ stream-format\=\(string\)byte-stream\,\ alignment\=\(string\)nal\,\ width\=\(int\)1024\,\ height\=\(int\)576\,\ framerate\=\(fraction\)25/1\,\ parsed\=\(boolean\)true\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ profile\=\(string\)main\,\ level\=\(string\)3.1";
1.6.0:
recieved two caps events
1. incomplete caps in caps event before rendering starts:
gstbasesink.c:3232:gst_base_sink_event:`<fakesink0>` received event 0x7f090c014dc0 caps event: 0x7f090c014dc0, time 99:99:99.999999999, seq-num 68, GstEventCaps, caps=(GstCaps)"video/x-h264\,\ stream-format\=\(string\)byte-stream\,\ alignment\=\(string\)nal\,\ parsed\=\(boolean\)true";
2. complete caps in caps event after rendering starts:
gstbasesink.c:3232:gst_base_sink_event:`<fakesink0>` received event 0x7f090c015010 caps event: 0x7f090c015010, time 99:99:99.999999999, seq-num 86, GstEventCaps, caps=(GstCaps)"video/x-h264\,\ stream-format\=\(string\)byte-stream\,\ alignment\=\(string\)nal\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ width\=\(int\)1024\,\ height\=\(int\)576\,\ framerate\=\(fraction\)25/1\,\ parsed\=\(boolean\)true\,\ profile\=\(string\)main\,\ level\=\(string\)3.1";
If I revert these two commits, then I have same behaviour as in 1.5.1:
http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=e8908f5aeef952566f6bccde743c7735d3f8c6ef
http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=48a1f2792316d01c4ea4c6baa27188ffae73c543
In e8908f5aeef952566f6bccde743c7735d3f8c6ef, I can see that we are updating src caps even if sps is not yet available.
Is this correct behaviour to update src caps with incomplete caps, first?
Thank you
**Attachment 312435**, "h264parse log 1.5.1 and 1.6.0 comparison":
[h264parse_151_160.tar.gz](/uploads/5fb5455df49e6006e088f8595949a964/h264parse_151_160.tar.gz)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/176h264parse: sets parsed=true on output even in passthrough mode2021-09-24T14:32:47ZBugzilla Migration Userh264parse: sets parsed=true on output even in passthrough mode## Submitted by Matej `@Knopp`
**[Link to original bug (#737487)](https://bugzilla.gnome.org/show_bug.cgi?id=737487)**
## Description
This doesn't seem right. Just because both input and output are in same format, the parser should ...## Submitted by Matej `@Knopp`
**[Link to original bug (#737487)](https://bugzilla.gnome.org/show_bug.cgi?id=737487)**
## Description
This doesn't seem right. Just because both input and output are in same format, the parser should claim that it has parsed the input and then enable passthrough.
In may case matroskademux output AVC H.264 (unparsed), decoder requires AVC with parsed=true and parser just appends parsed=true to the caps without even looking at the stream.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/578h264parse: should not always add latency2020-05-27T22:52:05ZBugzilla Migration Userh264parse: should not always add latency## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#784329)](https://bugzilla.gnome.org/show_bug.cgi?id=784329)**
## Description
h264parse always announces one frame latency (gst_base_parse_set_latency) while a...## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#784329)](https://bugzilla.gnome.org/show_bug.cgi?id=784329)**
## Description
h264parse always announces one frame latency (gst_base_parse_set_latency) while actually it depends on the input and output caps.
Latency should only be added when input is 'alignment=nal' and output is 'alignment=au'.