GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T12:52:25Zhttps://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/36gst-libav: configure exits with no error status if configuring internal libav...2021-09-24T12:52:25ZBugzilla Migration Usergst-libav: configure exits with no error status if configuring internal libav fails## Submitted by Alistair Buxton
**[Link to original bug (#794912)](https://bugzilla.gnome.org/show_bug.cgi?id=794912)**
## Description
Here the configure for gst-libav runs the configure for libav:
https://cgit.freedesktop.org/...## Submitted by Alistair Buxton
**[Link to original bug (#794912)](https://bugzilla.gnome.org/show_bug.cgi?id=794912)**
## Description
Here the configure for gst-libav runs the configure for libav:
https://cgit.freedesktop.org/gstreamer/gst-libav/tree/configure.ac#n464
If for some reason the libav configuration fails, the gst-libav configuration does not return an error status. This means if you are building from a script or Makefile, then that script will not realise that an error has occured and will continue to attempt to build gst-libav, with undefined results.
I encountered this in the context of 39df65e8a27496650ea7c36d8d91f48b770ec46a. If I try to build from the commit prior to this one, libav configure will fail as it cannot find gas-preprocessor. Despite this, attempting to compile gst-libav still "succeeds" - in the sense that it also does not return an error. I have no idea what it actually produces, but my build scripts happily pack it up and report success.https://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/35Library path switch in gst-libs/ext/Makefile.am causes cross compilation errors2021-09-24T12:52:24ZBugzilla Migration UserLibrary path switch in gst-libs/ext/Makefile.am causes cross compilation errors## Submitted by Carlos Rafael Giani
**[Link to original bug (#794621)](https://bugzilla.gnome.org/show_bug.cgi?id=794621)**
## Description
In gst-libs/ext/akefile.am , there is this line:
echo "dependency_libs=' -L$(libdir) $...## Submitted by Carlos Rafael Giani
**[Link to original bug (#794621)](https://bugzilla.gnome.org/show_bug.cgi?id=794621)**
## Description
In gst-libs/ext/akefile.am , there is this line:
echo "dependency_libs=' -L$(libdir) $(if $2,$(foreach dep,$2,$(abs_builddir)/$(dep).la)) $(call find_library_la,$3 $(LIBM),$(LDFLAGS)) '" && \
When trying to cross compile gst-libav 1.14.0 with Yocto rocko, this causes a problem.
libdir is set to /usr/lib, so -L/usr/lib is passed to the compiler. Yocto detects this switch, and considers it a hard error.
It is possible that GCC indeed is translating the path properly, but Yocto sees this path, and assumes that it is specifying an unsafe path to the host's libraries. Either way, this makes it impossible to build gst-libav 1.14.0 with Yocto.
Possible solutions are to either (a) stick with a Yocto patch against gst-libav that removes the -L switch, (b) manually append the sysroot to this -L switch path, or (c) silence the Yocto error (not recommended).
Note that other cross compilation environments that check the -I and -L paths are also likely to encounter this problem.
Version: 1.14.0https://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/34libav: add avsrc2021-09-24T12:52:24ZBugzilla Migration Userlibav: add avsrc## Submitted by Nicola `@drakkan`
**[Link to original bug (#788583)](https://bugzilla.gnome.org/show_bug.cgi?id=788583)**
## Description
Created attachment 361025
add avsrc
This patch add an avsrc element. I use it to receive...## Submitted by Nicola `@drakkan`
**[Link to original bug (#788583)](https://bugzilla.gnome.org/show_bug.cgi?id=788583)**
## Description
Created attachment 361025
add avsrc
This patch add an avsrc element. I use it to receive rtmp streams.
I think the patch should be improved in several ways to be accepted upstream, anyway it works fine for my use case as is and for now I have no more time to work on it.
I think this patch can help other people that have to deal with rtmp in gstreamer to save time.
rtmp support in ffmpeg seems quite good and well supported, it works perfectly with the stream I have to receive, for example rtmp2 element is unable to receive them.
To enable avsrc element you need to enable network protocols in libav for example configuring it this way:
./configure --with-libav-extra-configure="--enable-network --enable-openssl --enable-protocol=rtmp --enable-protocol=rtmpe --enable-protocol=rtmps --enable-protocol=rtmpt --enable-protocol=rtmpte --enable-protocol=rtmpts --enable-protocol=tls_openssl"
**Patch 361025**, "add avsrc":
[0001-add-avsrc-element.patch](/uploads/9048ccc9e2ce69ecc742ebefc9f78e59/0001-add-avsrc-element.patch)
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/33Both videomixer and glvideomixer do not want to work properly with avdec_h264...2021-09-24T12:52:23ZBugzilla Migration UserBoth videomixer and glvideomixer do not want to work properly with avdec_h264 decoder## Submitted by Eugen Klim
**[Link to original bug (#779807)](https://bugzilla.gnome.org/show_bug.cgi?id=779807)**
## Description
Hello. I want to build a graph which would mix pictures from a few h264 streams into one frame (so cal...## Submitted by Eugen Klim
**[Link to original bug (#779807)](https://bugzilla.gnome.org/show_bug.cgi?id=779807)**
## Description
Hello. I want to build a graph which would mix pictures from a few h264 streams into one frame (so called ``picture in picture''). It seems that videomixer element is the right thing to do the trick. And videomixer works as expected with videotestsrc [graph_0.sh]. However, when I build graph with h264 decoder [graph_2.sh], it fails with an error:
>ERROR: from element /GstPipeline:pipeline0/MpegTSParse2:mpegtsparse2-0: Internal data stream error.
>Additional debug info:
>mpegtsbase.c(1613): mpegts_base_loop (): /GstPipeline:pipeline0/MpegTSParse2:mpegtsparse2-0:
>streaming stopped, reason not-negotiated (-4)
But when I switch videomixer with glvideomixer [graph_3.sh] it works fine. However, if I add background via videotestsrc, it also fails [graph_3b.sh].
Graph with decodebin and glvideomixer also works [graph_4.sh], but graph with decodebin, glvideomixer and videotestsrc background [graph_4b.sh] -- does not.
But I've noticed that [graph_4b.sh] works perfectly with mpeg2 decoded ts, while failing with h264 stream.
I could not understand what's the problem, but it seems that the problem is avdec_h264 related, so I need some help. I'm not sure is it a bug or am i doing something wrong.
I've attached graph scripts and 2 test streams (mpeg2 and h264).
Thank you.
Version: 1.10.xhttps://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/30gstavviddec posts incorrect latency2021-09-24T12:52:21ZBugzilla Migration Usergstavviddec posts incorrect latency## Submitted by Baby octopus
**[Link to original bug (#773084)](https://bugzilla.gnome.org/show_bug.cgi?id=773084)**
## Description
gstavviddec is always posting single frame latency irrespective of B frames. Latency would certainly...## Submitted by Baby octopus
**[Link to original bug (#773084)](https://bugzilla.gnome.org/show_bug.cgi?id=773084)**
## Description
gstavviddec is always posting single frame latency irrespective of B frames. Latency would certainly creep in for reordering B picture
Following sender and receiver pipeline can be used to demonstrate the issue
Sender:
gst-launch-1.0 videotestsrc ! video/x-raw,width=320,height=240 ! x264enc bframes=4 key-int-max=25 b-adapt=0 ! mpegtsmux ! udpsink host=10.0.90.1 port=8000
Receiver:
gst-launch-1.0 udpsrc port=8000 ! tsdemux ! h264parse ! avdec_h264 ! fakesink sync=1 --gst-debug=basesink:5
The latency seen at basesink at the receiver side is always a single frame latency(733ms - 700ms belongs to tsdemux)
Version: 1.9.90https://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/29avdemux: check if we ran outside of the segment2021-09-24T12:52:21ZBugzilla Migration Useravdemux: check if we ran outside of the segment## Submitted by WeiChungChang
**[Link to original bug (#772730)](https://bugzilla.gnome.org/show_bug.cgi?id=772730)**
## Description
Dear all:
I wonder the correctness about the flow within Gstavdemux to check if we ran outsi...## Submitted by WeiChungChang
**[Link to original bug (#772730)](https://bugzilla.gnome.org/show_bug.cgi?id=772730)**
## Description
Dear all:
I wonder the correctness about the flow within Gstavdemux to check if we ran outside of the segment.
Please see the following flow.
/* do timestamps, we do this first so that we can know when we
* stepped over the segment stop position. */
timestamp = gst_ffmpeg_time_ff_to_gst (pkt.pts, avstream->time_base);
if (GST_CLOCK_TIME_IS_VALID (timestamp)) {
stream->last_ts = timestamp;
}
...
if (GST_CLOCK_TIME_IS_VALID (timestamp))
timestamp -= demux->start_time;
...
/* check if we ran outside of the segment */
if (demux->segment.stop != -1 && timestamp > demux->segment.stop)
goto drop;
When we are given the settings below and it means we want to playback P1 B3 B4 only.
Presentation order = I1 B1 B2 { P1 B3 B4 } I2
decoding order = I1 P1 B1 B2 I2 B3 B4
PTS of ( I1 B1 B2 P1 B3 B4 I2) = ( 1, 2, 3, 4, 5, 6, 7)
DTS of ( I1 B1 B2 P1 B3 B4 I2) = (1, 3, 4, 2, 6, 7, 5)
The segment stop is set to "6" accordingly since the PTS of {P1 B3 B4} = ( 4, 5, 6 ).
However, notice that the PTS of I2 is "7" which is larger than 6. Also we will demux it before B3 & B4.
By the flow : "check if we ran outside of the segment", we will go to the drop label & pause where.
The result is we miss the following two B frames, which should be played originally.
I think an additional check such as "if we have met the first Key frame whose PTS is greater than segment's stop, go to drop (pause)" will be safe.
Thanks.https://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/28avdec_wmalossless: Add support for 24-bit format2021-09-24T12:52:20ZBugzilla Migration Useravdec_wmalossless: Add support for 24-bit format## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#772018)](https://bugzilla.gnome.org/show_bug.cgi?id=772018)**
## Description
The upstream ffmpeg now fully supports 24-bit PCM output for WMA Lossless, not only 16 bi...## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#772018)](https://bugzilla.gnome.org/show_bug.cgi?id=772018)**
## Description
The upstream ffmpeg now fully supports 24-bit PCM output for WMA Lossless, not only 16 bit.
The problem is that when getting data in this mode, it produces one valid output frame for 3 input frames. I'm attaching a patch that makes it work, but I'm totally unsure if it does the right thing.
Here is a test file: http://people.freedesktop.org/~tester/45s-96khz-24bit-51ch-lossless.wmahttps://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/27Shotwell crashes on import2021-09-24T12:52:20ZBugzilla Migration UserShotwell crashes on import## Submitted by geert jordaens
**[Link to original bug (#769050)](https://bugzilla.gnome.org/show_bug.cgi?id=769050)**
## Description
Created attachment 331903
Log file produced with SHOTWELL_LOG=1 gdb shotwell 2>&1 | tee shotwell...## Submitted by geert jordaens
**[Link to original bug (#769050)](https://bugzilla.gnome.org/show_bug.cgi?id=769050)**
## Description
Created attachment 331903
Log file produced with SHOTWELL_LOG=1 gdb shotwell 2>&1 | tee shotwell.gdb
Shotwell crashes on import from camera.
After copying the files manually in the libray shotwell crashes when updating the library.
Photos taken with Canon 30D
**Attachment 331903**, "Log file produced with SHOTWELL_LOG=1 gdb shotwell 2>&1 | tee shotwell.gdb":
[shotwell.log](/uploads/dcc856a0918eee93ff1a9c8c91d83900/shotwell.log)
Version: 1.8.2https://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/26Use coded_width/height which is now also available from ffmpeg2021-09-24T12:52:19ZBugzilla Migration UserUse coded_width/height which is now also available from ffmpeg## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#764544)](https://bugzilla.gnome.org/show_bug.cgi?id=764544)**
## Description
https://ffmpeg.org/pipermail/ffmpeg-devel/2016-April/192507.html
See [bug 752802](h...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#764544)](https://bugzilla.gnome.org/show_bug.cgi?id=764544)**
## Description
https://ffmpeg.org/pipermail/ffmpeg-devel/2016-April/192507.html
See [bug 752802](https://bugzilla.gnome.org/show_bug.cgi?id=752802) (and probably others) where we could've made use of knowing the uncropped width/height.https://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/25Many video encoders fail to negotiate the source format2021-09-24T12:52:19ZBugzilla Migration UserMany video encoders fail to negotiate the source format## Submitted by Francois Gouget
**[Link to original bug (#756004)](https://bugzilla.gnome.org/show_bug.cgi?id=756004)**
## Description
It looks like more video encoders have a similar source format negotiation problem to [bug 750398...## Submitted by Francois Gouget
**[Link to original bug (#756004)](https://bugzilla.gnome.org/show_bug.cgi?id=756004)**
## Description
It looks like more video encoders have a similar source format negotiation problem to [bug 750398](https://bugzilla.gnome.org/show_bug.cgi?id=750398):
To reproduce the problem simply run:
$ GST_DEBUG=1 gst-launch-1.0 videotestsrc num-buffers=40 ! videoconvert ! avenc_apng ! fakesink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0: Internal data flow error.
Additional debug info:
gstbasesrc.c(2943): gst_base_src_loop (): /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0:
streaming task paused, reason not-negotiated (-4)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...
Here is a list of the video encoders that seem to be broken:
avenc_alias_pix
avenc_apng
avenc_avrp
avenc_avui
avenc_ayuv
avenc_dpx
avenc_flashsv2
avenc_jpeg2000
avenc_jpegls
avenc_pbm
avenc_r10k
avenc_snow
avenc_sunrast
avenc_utvideo
avenc_v308
avenc_v408
avenc_v410
avenc_xbm
avenc_xface
avenc_xwd
avenc_y41p
avenc_yuv4
In each case it looks like videoconvert should be able to convert the source image format into the format needed by the encoder.
Version: 1.6.0https://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/24avenc_mjpeg does not play well with appsrc do-timestamp=true2021-09-24T12:52:18ZBugzilla Migration Useravenc_mjpeg does not play well with appsrc do-timestamp=true## Submitted by Francois Gouget
**[Link to original bug (#753257)](https://bugzilla.gnome.org/show_bug.cgi?id=753257)**
## Description
Spice (http://www.spice-space.org/) provides access to remote desktops, particularly in virtualiz...## Submitted by Francois Gouget
**[Link to original bug (#753257)](https://bugzilla.gnome.org/show_bug.cgi?id=753257)**
## Description
Spice (http://www.spice-space.org/) provides access to remote desktops, particularly in virtualized environments. One of the features is the auto-detection and reencoding of videos to limit bandwidth and ensure smooth playback over the network. Currently it uses an internal MJPEG encoder and I'm adding GStreamer support so more options are available.
The pipeline is:
appsrc format=2 do-timestamp=true ! videoconvert ! avenc_mjpeg ! appsink
The problem is avenc_mjpeg quickly locks up with the following message:
0:00:00.845940069 23436 0x7f5318649800 ERROR libav :0:: Error, Invalid timestamp=12, last=12
The issue is that the frame rate is not really constant as it depends on the delays occurring in the virtual machine's media player and in Spice, and also that we only have an estimate of the fps. So the DTS and PTS timestamps appsrc puts on the buffers are not evenly spaced. Actually I'm not entirely sure why they are even set since we set the format to GST_FORMAT_BYTES.
In the above case we had an estimated fps of 18, and the following buffer timestamps:
002513154 -> 0.0450 -> 0
071591170 -> 1.2870 -> 1
118313226 -> 2.1294 -> 2
165181751 -> 2.9718 -> 3
245834444 -> 4.4244 -> 4
332598247 -> 5.9850 -> 6
371301628 -> 6.6834 -> 7
418700233 -> 7.5366 -> 8
506639922 -> 9.1188 -> 9
544309390 -> 9.7974 -> 10
591892626 -> 10.6524 -> 11
639620343 -> 11.5128 -> 12
677606008 -> 12.1968 -> 12
vp8enc and x264enc have no problem with the timestamps produced by appsrc so I'd expect avenc_mjpeg to work with them too.
[Bug 724103](https://bugzilla.gnome.org/show_bug.cgi?id=724103) looks similar but it has not seen a resolution so far.
Here are the relevant GStreamer traces:
0:00:00.168343602 23436 0x7f5318649800 LOG GST_SCHEDULING gstpad.c:3828:gst_pad_chain_data_unchecked:<encoder:sink> calling chainfunction &gst_video_encoder_chain with buffer buffer: 0x7f531864f730, pts 0:00:00.002513154, dts 0:00:00.002513154, dur 99:99:99.999999999, size 2536960, offset 1, offset_end 18446744073709551615, flags 0x0
0:00:00.235083367 23436 0x7f5318649800 LOG GST_SCHEDULING gstpad.c:3828:gst_pad_chain_data_unchecked:<encoder:sink> calling chainfunction &gst_video_encoder_chain with buffer buffer: 0x7f531864f730, pts 0:00:00.071591170, dts 0:00:00.071591170, dur 99:99:99.999999999, size 2536960, offset 2, offset_end 18446744073709551615, flags 0x0
0:00:00.281803710 23436 0x7f5318649800 LOG GST_SCHEDULING gstpad.c:3828:gst_pad_chain_data_unchecked:<encoder:sink> calling chainfunction &gst_video_encoder_chain with buffer buffer: 0x7f531864f730, pts 0:00:00.118313226, dts 0:00:00.118313226, dur 99:99:99.999999999, size 2536960, offset 3, offset_end 18446744073709551615, flags 0x0
0:00:00.331504042 23436 0x7f5318649800 LOG GST_SCHEDULING gstpad.c:3828:gst_pad_chain_data_unchecked:<encoder:sink> calling chainfunction &gst_video_encoder_chain with buffer buffer: 0x7f531864f730, pts 0:00:00.165181751, dts 0:00:00.165181751, dur 99:99:99.999999999, size 2536960, offset 4, offset_end 18446744073709551615, flags 0x0
0:00:00.409095156 23436 0x7f5318649800 LOG GST_SCHEDULING gstpad.c:3828:gst_pad_chain_data_unchecked:<encoder:sink> calling chainfunction &gst_video_encoder_chain with buffer buffer: 0x7f531864f730, pts 0:00:00.245834444, dts 0:00:00.245834444, dur 99:99:99.999999999, size 2536960, offset 5, offset_end 18446744073709551615, flags 0x0
0:00:00.497658441 23436 0x7f5318649800 LOG GST_SCHEDULING gstpad.c:3828:gst_pad_chain_data_unchecked:<encoder:sink> calling chainfunction &gst_video_encoder_chain with buffer buffer: 0x7f531864f730, pts 0:00:00.332598247, dts 0:00:00.332598247, dur 99:99:99.999999999, size 2536960, offset 6, offset_end 18446744073709551615, flags 0x0
0:00:00.534940768 23436 0x7f5318649800 LOG GST_SCHEDULING gstpad.c:3828:gst_pad_chain_data_unchecked:<encoder:sink> calling chainfunction &gst_video_encoder_chain with buffer buffer: 0x7f531864f730, pts 0:00:00.371301628, dts 0:00:00.371301628, dur 99:99:99.999999999, size 2536960, offset 7, offset_end 18446744073709551615, flags 0x0
0:00:00.582394393 23436 0x7f5318649800 LOG GST_SCHEDULING gstpad.c:3828:gst_pad_chain_data_unchecked:<encoder:sink> calling chainfunction &gst_video_encoder_chain with buffer buffer: 0x7f531864f730, pts 0:00:00.418700233, dts 0:00:00.418700233, dur 99:99:99.999999999, size 2536960, offset 8, offset_end 18446744073709551615, flags 0x0
0:00:00.670202868 23436 0x7f5318649800 LOG GST_SCHEDULING gstpad.c:3828:gst_pad_chain_data_unchecked:<encoder:sink> calling chainfunction &gst_video_encoder_chain with buffer buffer: 0x7f531864f730, pts 0:00:00.506639922, dts 0:00:00.506639922, dur 99:99:99.999999999, size 2536960, offset 9, offset_end 18446744073709551615, flags 0x0
0:00:00.707709735 23436 0x7f5318649800 LOG GST_SCHEDULING gstpad.c:3828:gst_pad_chain_data_unchecked:<encoder:sink> calling chainfunction &gst_video_encoder_chain with buffer buffer: 0x7f531864f730, pts 0:00:00.544309390, dts 0:00:00.544309390, dur 99:99:99.999999999, size 2536960, offset 10, offset_end 18446744073709551615, flags 0x0
0:00:00.756213906 23436 0x7f5318649800 LOG GST_SCHEDULING gstpad.c:3828:gst_pad_chain_data_unchecked:<encoder:sink> calling chainfunction &gst_video_encoder_chain with buffer buffer: 0x7f531864f730, pts 0:00:00.591892626, dts 0:00:00.591892626, dur 99:99:99.999999999, size 2536960, offset 11, offset_end 18446744073709551615, flags 0x0
0:00:00.803863082 23436 0x7f5318649800 LOG GST_SCHEDULING gstpad.c:3828:gst_pad_chain_data_unchecked:<encoder:sink> calling chainfunction &gst_video_encoder_chain with buffer buffer: 0x7f531864f730, pts 0:00:00.639620343, dts 0:00:00.639620343, dur 99:99:99.999999999, size 2536960, offset 12, offset_end 18446744073709551615, flags 0x0
0:00:00.845885669 23436 0x7f5318649800 LOG GST_SCHEDULING gstpad.c:3828:gst_pad_chain_data_unchecked:<encoder:sink> calling chainfunction &gst_video_encoder_chain with buffer buffer: 0x7f531864f730, pts 0:00:00.677606008, dts 0:00:00.677606008, dur 99:99:99.999999999, size 2536960, offset 13, offset_end 18446744073709551615, flags 0x0
0:00:00.845940069 23436 0x7f5318649800 ERROR libav :0:: Error, Invalid timestamp=12, last=12
0:00:00.845960574 23436 0x7f5318649800 ERROR libav gstavvidenc.c:675:gst_ffmpegvidenc_handle_frame:`<encoder>` avenc_mjpeg: failed to encode buffer
0:00:00.845970442 23436 0x7f5318649800 DEBUG videoencoder gstvideoencoder.c:1902:gst_video_encoder_finish_frame:`<encoder>` skipping frame 0:00:00.677606008
Version: 1.6.0https://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/23Can't specify muxer options for avformat_write_header2021-09-24T12:52:18ZBugzilla Migration UserCan't specify muxer options for avformat_write_header## Submitted by David Sansome `@davidsansome`
**[Link to original bug (#751772)](https://bugzilla.gnome.org/show_bug.cgi?id=751772)**
## Description
Created attachment 306476
Allow libav muxer-specific options to be passed to muxe...## Submitted by David Sansome `@davidsansome`
**[Link to original bug (#751772)](https://bugzilla.gnome.org/show_bug.cgi?id=751772)**
## Description
Created attachment 306476
Allow libav muxer-specific options to be passed to muxer elements
I'd like to be able to pass muxer-specific options to the second argument of avformat_write_header (http://ffmpeg.org/doxygen/trunk/group__lavf__encoding.html#ga78d4e734fecb1d2385536e6dd5b7b9f5), specifically to let me configure the mp4 muxer to output fragmented mp4 files with -movflags empty_moov and -frag_duration `<n>`.
The attached patch adds an "options" property to all muxers that's a ':' separated list of option=value pairs to be added to this options dict.
**Patch 306476**, "Allow libav muxer-specific options to be passed to muxer elements":
[0001-Allow-libav-muxer-specific-options-to-be-passed-to-m.patch](/uploads/1f9b79901b05757c477769aba12983eb/0001-Allow-libav-muxer-specific-options-to-be-passed-to-m.patch)https://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/22avvideodec: outputs gray frames for non-keyframes when configured to operate ...2021-09-24T12:52:18ZBugzilla Migration Useravvideodec: outputs gray frames for non-keyframes when configured to operate in TRICKMODE_KEYUNIT## Submitted by Tim Müller `@tpm`
**[Link to original bug (#750055)](https://bugzilla.gnome.org/show_bug.cgi?id=750055)**
## Description
Reproduce with:
gst-play-1.0 ~/foo.mkv
Make sure e.g. avdec_h264 is used.
Pres...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#750055)](https://bugzilla.gnome.org/show_bug.cgi?id=750055)**
## Description
Reproduce with:
gst-play-1.0 ~/foo.mkv
Make sure e.g. avdec_h264 is used.
Press 't' three times until it says '(trick mode: key frames only)'
What happens:
The output is gray frames with occasionally a picture showing up (presumably where there's a keyframe).
What should happen:
Only decoded key frames should be output, no gray frames in between.
This works fine if the demuxer is aware of the trick mode and only outputs keyframes in the first place of course (like qtdemux does).
Note that the demuxer flags buffers correctly as key-frame/delta-unit here.
It's just that libav appears to output gray frames for non-keyframes.
I'm not sure if this is a bug in libav or if we're supposed to look at the pict_type and drop the frame in avviddec if needed (which we can easily do of course).https://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/21avdec_* report interlaced content as "mixed" instead of "interleaved"2021-09-24T12:52:17ZBugzilla Migration Useravdec_* report interlaced content as "mixed" instead of "interleaved"## Submitted by FredT
**[Link to original bug (#749930)](https://bugzilla.gnome.org/show_bug.cgi?id=749930)**
## Description
FFMPEG decoder such as mpeg2dec and libav decoder avdec_h264 does not report interlaced content correctly. ...## Submitted by FredT
**[Link to original bug (#749930)](https://bugzilla.gnome.org/show_bug.cgi?id=749930)**
## Description
FFMPEG decoder such as mpeg2dec and libav decoder avdec_h264 does not report interlaced content correctly. This problem could exist in other decoder when producing interlaced output.
Currently the Gstreamer implementation report GST_VIDEO_INTERLACE_MODE_MIXED
To the best of my knowledge, I believe this is wrong as FFMPEG/LIBAV produce Interlace Interleaved frame. 1 frame contains both top and bottom field.
This came to light while testing the new decklink video sink.
I replaced the GST_VIDEO_INTERLACE_MODE_MIXED flag in gstavviddec.c for avdec_h264 and gstmpeg2dec.c for mpeg2 decoder.
After the modification i was able to output video at 1080i59.94 without issues.
Before the change, the following line as an example did not work since decklinksink is expecting interlace-interleaved source:
gst-launch-1.0 -v --gst-debug-level=3 udpsrc uri="udp://239.127.23.2:5724" buffer-size=5000000 ! queue ! tsdemux ! h264parse ! queue ! avdec_h264 ! queue ! videoconvert ! queue ! videorate ! queue ! decklinkvideosink mode=12https://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/18libav: Video decoder push buffer mapped in READ/WRITE2021-09-24T12:52:16ZBugzilla Migration Userlibav: Video decoder push buffer mapped in READ/WRITE## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#740222)](https://bugzilla.gnome.org/show_bug.cgi?id=740222)**
## Description
While looking into adding features in glbufferpool to allow liav direct rendering t...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#740222)](https://bugzilla.gnome.org/show_bug.cgi?id=740222)**
## Description
While looking into adding features in glbufferpool to allow liav direct rendering to work, I notice that avviddec was actually mapping buffers
in READ/WRITE. When memory a GL textures, this would cause a download
to occur.
Version: 1.4.4
### Depends on
* [Bug 754826](https://bugzilla.gnome.org/show_bug.cgi?id=754826)https://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/17avdemux_ape0 can not work when getting audio data from http data2022-06-28T10:59:08ZBugzilla Migration Useravdemux_ape0 can not work when getting audio data from http data## Submitted by soh..@..il.com
**[Link to original bug (#738807)](https://bugzilla.gnome.org/show_bug.cgi?id=738807)**
## Description
gstreamer I use is v1.4.1.
in the code gstavdemux.c, it set avdemux_ape in blacklist.
it mea...## Submitted by soh..@..il.com
**[Link to original bug (#738807)](https://bugzilla.gnome.org/show_bug.cgi?id=738807)**
## Description
gstreamer I use is v1.4.1.
in the code gstavdemux.c, it set avdemux_ape in blacklist.
it means avdemux_ape can not work in push mode,
Why avdemux_ape cannot work in push mode?
Is there any limitation?
if I try to set demux->can_push = TRUE; for ape,
then I got the error :
stream_movi flow: error / error
pausing task, reason -5 (error)
Any solution for ape to work when playing from http ?
since dlna application will use http protocol to get audio data , other audio format can be download via http protocol, when ape audio file can not be download from http?
Version: 1.4.1https://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/16Use AVInputFormat.name instead of AVInputFormat.long_name for container formats2021-09-24T12:52:14ZBugzilla Migration UserUse AVInputFormat.name instead of AVInputFormat.long_name for container formats## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#738060)](https://bugzilla.gnome.org/show_bug.cgi?id=738060)**
## Description
long_name is meant to be human readable and can change, while name is a comma separated ...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#738060)](https://bugzilla.gnome.org/show_bug.cgi?id=738060)**
## Description
long_name is meant to be human readable and can change, while name is a comma separated list of machine usable container format names. long_name can change or be reformatted any time.
Also long_name can be NULL, especially if building libav/ffmpeg with --enable-smallhttps://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/12Fail to negotiate pipeline using rtph263ppay, avenc_h263p and a fixed caps fi...2021-09-24T12:52:13ZBugzilla Migration UserFail to negotiate pipeline using rtph263ppay, avenc_h263p and a fixed caps filter## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#729555)](https://bugzilla.gnome.org/show_bug.cgi?id=729555)**
## Description
The following pipeline works "gst-launch-1.0 videotestsrc ! avenc_h263p ! rtph263...## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#729555)](https://bugzilla.gnome.org/show_bug.cgi?id=729555)**
## Description
The following pipeline works "gst-launch-1.0 videotestsrc ! avenc_h263p ! rtph263ppay ! udpsink" but this one doesn't:
$ gst-launch-1.0 -v videotestsrc ! avenc_h263p ! rtph263ppay ! application/x-rtp ! udpsink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
/GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0.GstPad:src: caps = video/x-raw, format=(string)I420, width=(int)320, height=(int)240, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive
/GstPipeline:pipeline0/avenc_h263p:avenc_h263p0.GstPad:sink: caps = video/x-raw, format=(string)I420, width=(int)320, height=(int)240, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive
ERROR: from element /GstPipeline:pipeline0/avenc_h263p:avenc_h263p0: GStreamer error: negotiation problem.
Additional debug info:
gstvideoencoder.c(1368): gst_video_encoder_chain (): /GstPipeline:pipeline0/avenc_h263p:avenc_h263p0:
encoder not initialized
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
/GstPipeline:pipeline0/avenc_h263p:avenc_h263p0.GstPad:sink: caps = NULL
/GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0.GstPad:src: caps = NULL
Freeing pipeline ...
In the first pipeline, gst_ffmpeg_caps_with_codecid() is called with "video/x-h263, variant=(string)itu" (1 struct) and so everything works fine.
But in the second one, it's called with "video/x-h263, variant=(string)itu, h263version=(string)h263, annex-f=(boolean)false, annex-i=(boolean)false, annex-j=(boolean)false, annex-t=(boolean)false; video/x-h263, variant=(string)itu, h263version=(string)h263" (2 structs); this function only use the first structure and so it fails to negotiate.https://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/4DCA/AAC/AC-3 decoders broken in gst-libav2021-09-24T12:52:10ZBugzilla Migration UserDCA/AAC/AC-3 decoders broken in gst-libav## Submitted by ros..@..il.com
**[Link to original bug (#608892)](https://bugzilla.gnome.org/show_bug.cgi?id=608892)**
## Description
In most of my videos, I only get some of the channels (usually the background music, sometimes sou...## Submitted by ros..@..il.com
**[Link to original bug (#608892)](https://bugzilla.gnome.org/show_bug.cgi?id=608892)**
## Description
In most of my videos, I only get some of the channels (usually the background music, sometimes sound effects) on my stereo setup. Non-gstreamer players grok them fine though, including mplayer, vlc, and xine.
I have all the gst-plugins-* packages installed, with most external dependencies installed. I have tried to build gst-ffmpeg with internal ffmpeg, external ffmpeg 0.5 and svn (several snapshots from 0.5 to now) with no luck. I just found out that installing libdca and the associated (-bad) plugin seems to work.
I'm using the onboard sound on an Asus M4A785G HTPC motherboard[0], which is a VIA VT2020 (snd-hda-codec-via), connected to an amplifier using the two RCA outputs on the back.
[0] http://www.asus.com/product.aspx?P_ID=uypox45wza0j3kz6https://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/3Use libavcodec codec's own downmixing2021-09-24T12:52:09ZBugzilla Migration UserUse libavcodec codec's own downmixing## Submitted by LRN
**[Link to original bug (#587570)](https://bugzilla.gnome.org/show_bug.cgi?id=587570)**
## Description
When i proposed to use ffdec_ac3 instead of a52dec as a default ac3 decoder (ffdec_ac3 is licensed under LGPL...## Submitted by LRN
**[Link to original bug (#587570)](https://bugzilla.gnome.org/show_bug.cgi?id=587570)**
## Description
When i proposed to use ffdec_ac3 instead of a52dec as a default ac3 decoder (ffdec_ac3 is licensed under LGPL and is being maintained by FFmpeg developers, while liba52 is in -ugly and looks unmaintained), __tim expressed some concerns about libavcodec's ability to decode and output multichannel audio and to do correct downstream downmixing negotiation (which supposedly means that libavocodec should heed the channel count requirements of downstream elements and use internal codec-specific downmixers to reduce the channel count instead of relying on audioconvert to do so).
Multichannel output in libavcodec is fairly stable (at least for ac3 decoder), and it should be, because 5.1 AC3s are very widespread these days.
Some of the libavcodec's codecs (ac3, mlp, dca and faad) are capable of performing internal downmixing. OK, we aren't very interested in dca (got dca-based decoder in -bad, with downmixing) and faad (same here, although libgstfaad does not use downmixing, which is available via faadcfg->downMatrix), but mlp and ac3 are desirable (since there is no mlp decoders in GStreamer and since ffdec_ac3 is LGPL), and with downmixing too!
So, i've made a patch that adds downmixing support to GstFFmpegDec. What it does:
* Exposes request_channels AVCodecContext as "request-channels" property of ffdec_* elements
* When request_channels is not set, ffmpegdec sets it up automatically to match the caps of downstream elements
The latter part is a bit shaky, but i hope that it works at least as good as the similar code in a52dec. Even if it doesn't, it's a good start.
To check the results of my changes, i decided to run a couple of tests. I had to use vorbis to encode various ac3 decoders' output, since i have to real multichannel hardware. Vorbis appears to be the only encoder capable of encoding 6-channel audio, except flac, which encodes it too, but with highly reduced volume level (dunno why it happens and i had no desire to find that out). I've performed tests only on combinations of 2 and 6 channel audio, for simplicity. I've used Audacity to open the resulting ogg-vorbis files and see the contents.
The test subject was this file - http://www.tfm.ro/ac3/download/test_ac3.rar (i've used ffmpeg -i "Test AC3 v2.0.avi" -acodec copy surround.ac3 to extract raw .ac3 audio stream)
The pipelines i've used:
gst-launch-0.10 filesrc location=surround.ac3 ! typefind ! ffdec_ac3 ! audioconvert ! audio/x-raw-float,channels=2 ! vorbisenc ! oggmux ! filesink location=surround_ffdec_ac3_org_e2.ogg
gst-launch-0.10 filesrc location=surround.ac3 ! typefind ! ffdec_ac3 ! audioconvert ! audio/x-raw-float,channels=6 ! vorbisenc ! oggmux ! filesink location=surround_ffdec_ac3_org_e6.ogg
gst-launch-0.10 filesrc location=surround.ac3 ! typefind ! ffdec_ac3 ! audioconvert ! vorbisenc ! oggmux ! filesink location=surround_ffdec_ac3_org_default.ogg
Replaced libgstffmpeg with modified version
gst-launch-0.10 filesrc location=surround.ac3 ! typefind ! ffdec_ac3 request-channels=2 ! audioconvert ! audio/x-raw-float,channels=2 ! vorbisenc ! oggmux ! filesink location=surround_ffdec_ac3_mod_r2e2.ogg
gst-launch-0.10 filesrc location=surround.ac3 ! typefind ! ffdec_ac3 request-channels=6 ! audioconvert ! audio/x-raw-float,channels=2 ! vorbisenc ! oggmux ! filesink location=surround_ffdec_ac3_mod_r6e2.ogg
gst-launch-0.10 filesrc location=surround.ac3 ! typefind ! ffdec_ac3 request-channels=2 ! audioconvert ! audio/x-raw-float,channels=6 ! vorbisenc ! oggmux ! filesink location=surround_ffdec_ac3_mod_r2e6.ogg
gst-launch-0.10 filesrc location=surround.ac3 ! typefind ! ffdec_ac3 request-channels=6 ! audioconvert ! audio/x-raw-float,channels=6 ! vorbisenc ! oggmux ! filesink location=surround_ffdec_ac3_mod_r6e6.ogg
gst-launch-0.10 filesrc location=surround.ac3 ! typefind ! ffdec_ac3 ! audioconvert ! vorbisenc ! oggmux ! filesink location=surround_ffdec_ac3_mod_default.ogg
For reference, the output from a52dec
gst-launch-0.10 filesrc location=surround.ac3 ! typefind ! a52dec mode=7 lfe=true ! audioconvert ! audio/x-raw-float,channels=6 ! vorbisenc ! oggmux ! filesink location=surround_a52dec_r6e6_lfe.ogg
gst-launch-0.10 filesrc location=surround.ac3 ! typefind ! a52dec mode=2 lfe=true ! audioconvert ! audio/x-raw-float,channels=6 ! vorbisenc ! oggmux ! filesink location=surround_a52dec_r2e6_lfe.ogg
gst-launch-0.10 filesrc location=surround.ac3 ! typefind ! a52dec mode=7 lfe=true ! audioconvert ! audio/x-raw-float,channels=2 ! vorbisenc ! oggmux ! filesink location=surround_a52dec_r6e2_lfe.ogg
gst-launch-0.10 filesrc location=surround.ac3 ! typefind ! a52dec mode=2 lfe=true ! audioconvert ! audio/x-raw-float,channels=2 ! vorbisenc ! oggmux ! filesink location=surround_a52dec_r2e2_lfe.ogg
gst-launch-0.10 filesrc location=surround.ac3 ! typefind ! a52dec mode=7 lfe=false ! audioconvert ! audio/x-raw-float,channels=6 ! vorbisenc ! oggmux ! filesink location=surround_a52dec_r6e6_nolfe.ogg
gst-launch-0.10 filesrc location=surround.ac3 ! typefind ! a52dec mode=2 lfe=false ! audioconvert ! audio/x-raw-float,channels=6 ! vorbisenc ! oggmux ! filesink location=surround_a52dec_r2e6_nolfe.ogg
gst-launch-0.10 filesrc location=surround.ac3 ! typefind ! a52dec mode=7 lfe=false ! audioconvert ! audio/x-raw-float,channels=2 ! vorbisenc ! oggmux ! filesink location=surround_a52dec_r6e2_nolfe.ogg
gst-launch-0.10 filesrc location=surround.ac3 ! typefind ! a52dec mode=2 lfe=false ! audioconvert ! audio/x-raw-float,channels=2 ! vorbisenc ! oggmux ! filesink location=surround_a52dec_r2e2_nolfe.ogg
gst-launch-0.10 filesrc location=surround.ac3 ! typefind ! a52dec mode=7 ! audioconvert ! audio/x-raw-float,channels=6 ! vorbisenc ! oggmux ! filesink location=surround_a52dec_r6e6_defaultlfe.ogg
gst-launch-0.10 filesrc location=surround.ac3 ! typefind ! a52dec mode=2 ! audioconvert ! audio/x-raw-float,channels=6 ! vorbisenc ! oggmux ! filesink location=surround_a52dec_r2e6_defaultlfe.ogg
gst-launch-0.10 filesrc location=surround.ac3 ! typefind ! a52dec mode=7 ! audioconvert ! audio/x-raw-float,channels=2 ! vorbisenc ! oggmux ! filesink location=surround_a52dec_r6e2_defaultlfe.ogg
gst-launch-0.10 filesrc location=surround.ac3 ! typefind ! a52dec mode=2 ! audioconvert ! audio/x-raw-float,channels=2 ! vorbisenc ! oggmux ! filesink location=surround_a52dec_r2e2_defaultlfe.ogg
gst-launch-0.10 filesrc location=surround.ac3 ! typefind ! a52dec lfe=true ! audioconvert ! vorbisenc ! oggmux ! filesink location=surround_a52dec_default_lfe.ogg
gst-launch-0.10 filesrc location=surround.ac3 ! typefind ! a52dec lfe=false ! audioconvert ! vorbisenc ! oggmux ! filesink location=surround_a52dec_default_nolfe.ogg
gst-launch-0.10 filesrc location=surround.ac3 ! typefind ! a52dec ! audioconvert ! vorbisenc ! oggmux ! filesink location=surround_a52dec_default.ogg
Conclusions:
* Despite what g_object_class_install_property (G_OBJECT_CLASS (klass), ARG_LFE, g_param_spec_boolean ("lfe", "LFE", "LFE", TRUE, G_PARAM_READWRITE)); says, LFE is disabled by default (or maybe a52dec disables it by itself in such circumstances)
* There is no lfe on/off switch in ffdec_ac3 (lfe is always on)
* Unpatched (request_channel-unaware) ffdec_ac3 outputs 6-channel audio by default (no downstream downmixing negotiation)
* When lfe is off, a52dec outputs mono audio without lfe by default (negotiates 1 channel?)
* Patched ffdec_ac3 outputs mono audio without lfe by default, just like a52dec with lfe=false (negotiates 1 channel?)
* When lfe is forced on, a52dec outputs 3-channel audio with lfe by default (negotiates 3 channels?)
* When 3 channels are requested, patched ffdec_ac3 outputs 3-channel audio with lfe (although the mixing strategy is different from default a52dec with lfe=false)
* When lfe is forced on and 2 channels are requested, a52dec outputs stereo with lfe
* When 2 channels are requested, patched ffdec_ac3 outputs stereo without lfe
* When lfe is forced on and 6 channels are requested, a52dec outputs 6ch audio with lfe
* When 6 channels are requested, patched ffdec_ac3 outputs 6ch audio with lfe
* When 2 or 3 channels are forced downstream, patched ffdec_ac3 behaves just as if 2 or 3 channels were explicitly requested from it (which means that negotiation works as intended)
* It seems that ffmpeg is being "smart" about lfe, discarding it when low-channel-count output is requested/negotiated, and preserving it when high-channel-cout output is requested/negotiated
surround.ac3 and the resulting ogg-vorbis files are available here - http://lrn.no-ip.info/other/gstreamer/surround_ffdec_ac3_vs_a52dec.7z