Opened 5 years ago

Last modified 17 months ago

#2737 open enhancement

There are discontinuous phenomenon in playing HLS stream when changing another bitrate stream

Reported by: felixyang_tw Owned by: stevenliu
Priority: wish Component: undetermined
Version: git-master Keywords: HLS
Cc: anssi.hannula@iki.fi Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

Dear all:

I use ffplay to play the hls stream (*.m3u8). It can play normally. However, as I try change the another bitrate stream by pressing 'a' (it will call stream_cycle_channel(cur_stream, AVMEDIA_TYPE_AUDIO)) or pressing 'a' (it will call stream_cycle_channel(cur_stream, AVMEDIA_TYPE_VIDEO)). There is discontinusous phenomenon people can perceive. Is there any method to change stream smoothly?

Change History (8)

comment:1 Changed 5 years ago by cehoyos

Please provide your command line together with the complete, uncut console output to make this a valid ticket.

comment:2 Changed 5 years ago by felixyang_tw

I use the following command to test:

ffplay http://192.168.1.10/video/test.m3u8

comment:3 Changed 5 years ago by cehoyos

To make this a valid ticket, please provide the failing command line together with the complete, uncut console output.

comment:4 Changed 5 years ago by sinkers

To assist with this ticket as I also have this issue please find console output here along with a good online reference stream.

It should be noted that this reference stream contains alternate audio and subtitle tracks neither of which seem to work with ffplay. Note I have extensive experience with HLS and happy to help out here providing any advice on how the player could be updated for this.

ffplay https://devimages.apple.com.edgekey.net/streaming/examples/bipbop_16x9/bipbop_16x9_variant.m3u8
ffplay version N-54126-g8cdea50 Copyright (c) 2003-2013 the FFmpeg developers

built on Jun 22 2013 19:20:40 with llvm-gcc 4.2.1 (LLVM build 2336.11.00)
configuration: --enable-gpl --enable-version3 --enable-nonfree --enable-postproc --enable-libaacplus --enable-libcelt --enable-libfaac --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-openssl --enable-libopus --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvo-aacenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxvid --prefix=/usr/local
libavutil 52. 37.101 / 52. 37.101
libavcodec 55. 16.100 / 55. 16.100
libavformat 55. 9.100 / 55. 9.100
libavdevice 55. 2.100 / 55. 2.100
libavfilter 3. 77.101 / 3. 77.101
libswscale 2. 3.100 / 2. 3.100
libswresample 0. 17.102 / 0. 17.102
libpostproc 52. 3.100 / 52. 3.100

It should also be noted that the startup for the playback is quite slow as it appears ffplay parses all the variant playlists before starting playback when it should just start playing on the first variant in the list and then adapt based on network conditions or user input. Happy to raise an additional ticket for this.

comment:5 Changed 5 years ago by cehoyos

  • Component changed from FFplay to undetermined
  • Priority changed from normal to wish

To make this a valid ticket, please provide the failing command line together with the complete, uncut console output (consider attaching the output as a text file if it is long).

comment:6 Changed 5 years ago by anssi

This is because HLS demuxer defers playlist reconfigs to segment switch times (I guess to try to achieve "clean" switches between streams without requesting overlapping segments from different variants).

However, when ffplay switches between streams, it does so "immediately" so that the packets from the HLS demuxer now get all ignored as they are from the current segment of the previous variant stream.

Either a) ffplay should continue playing the old stream until the first packet of the new stream arrives, or b) HLS demuxer should immediately switch to the new variant mid-segment.

Of course, with the b) option there would still be a (smaller) jump as ffplay needs to wait for a keyframe (IIRC). However, something like the b) option should be added anyway at least for alternative renditions, since one should be able to switch audio track or subtitle track without too much delay (and subtitle tracks may have very long segment times). I'm not 100% sure yet if it is a good idea for variant streams as well, though.

comment:7 Changed 4 years ago by anssi

  • Cc anssi.hannula@iki.fi added
  • Reproduced by developer set

The (b) option has been implemented in git master now.

While it made things significantly better, switchover is still not entirely smooth, which I think is because the player skips to the next keyframe when switching the video stream. Will keep this ticket open until that is fixed (will probably require FFplay changes, though).

comment:8 Changed 17 months ago by stevenliu

  • Owner set to stevenliu
  • Status changed from new to open

Try the newest version and check it from git-master please,

Note: See TracTickets for help on using tickets.