Possible bug in hlssink (gstreamer 1.16.1)

[David Ing]

The following command remuxes an audio.m4a file into HLS.

gst-launch-1.0 filesrc location="c:/tmp/audio.m4a" ! qtdemux name=a a.audio_0 ! queue ! aacparse ! queue ! mpegtsmux name=mux ! queue ! hlssink location="c:/tmp/hls_audio_only/%05d.ts" max-files=0 playlist-length=0 playlist-location=c:/tmp/hls_audio_only/index.m3u8 target-duration=8

Given that the target duration is 8 seconds, and my source file is 20 seconds, the output I expect is three *.ts files (each no greater than 8 seconds); and the *.m3u8 file.

Instead I get a single *.ts file and the playlist looks like this.

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-ALLOW-CACHE:NO
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-TARGETDURATION:20

#EXTINF:19.945941925048828,
00000.ts
#EXT-X-ENDLIST

The *.ts file is the same length as the audio input file, which is just a 19.94... second audio file which I uploaded here:  https://drive.google.com/file/d/1hN2EbRKJOa9HCrGBrLlUCLPHNg5VfdJh/view?usp=sharing

I only see this bug in audio-only scenarios.  I can build a similar kind of pipeline for video-only or audio+video and I get the expected output.

I am using gstreamer 1.16.1-msvc on Windows.

Can anyone provide guidance about what is broken and how I might fix it?

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[David Ing]

I just learned that this is a known bug:   https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/113

I will try using hlssink2 tomorrow (hoping it gets around the bug).

On Wed, Oct 23, 2019 at 9:58 AM David Ing <[hidden email]> wrote:

The following command remuxes an audio.m4a file into HLS.

gst-launch-1.0 filesrc location="c:/tmp/audio.m4a" ! qtdemux name=a a.audio_0 ! queue ! aacparse ! queue ! mpegtsmux name=mux ! queue ! hlssink location="c:/tmp/hls_audio_only/%05d.ts" max-files=0 playlist-length=0 playlist-location=c:/tmp/hls_audio_only/index.m3u8 target-duration=8

Given that the target duration is 8 seconds, and my source file is 20 seconds, the output I expect is three *.ts files (each no greater than 8 seconds); and the *.m3u8 file.

Instead I get a single *.ts file and the playlist looks like this.

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-ALLOW-CACHE:NO
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-TARGETDURATION:20

#EXTINF:19.945941925048828,
00000.ts
#EXT-X-ENDLIST

The *.ts file is the same length as the audio input file, which is just a 19.94... second audio file which I uploaded here:  https://drive.google.com/file/d/1hN2EbRKJOa9HCrGBrLlUCLPHNg5VfdJh/view?usp=sharing

I only see this bug in audio-only scenarios.  I can build a similar kind of pipeline for video-only or audio+video and I get the expected output.

I am using gstreamer 1.16.1-msvc on Windows.

Can anyone provide guidance about what is broken and how I might fix it?

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel