Opened 11 years ago

Last modified 7 years ago

#2737 open enhancement

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

Reported by: Felix Yang Owned by: Steven Liu
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 by Carl Eugen Hoyos, 11 years ago

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

comment:2 by Felix Yang, 11 years ago

I use the following command to test:

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

comment:3 by Carl Eugen Hoyos, 11 years ago

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

comment:4 by Andrew, 11 years ago

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 by Carl Eugen Hoyos, 11 years ago

Component: FFplayundetermined
Priority: normalwish

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 by Anssi Hannula, 10 years ago

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 by Anssi Hannula, 10 years ago

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 by Steven Liu, 7 years ago

Owner: set to Steven Liu
Status: newopen

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

Note: See TracTickets for help on using tickets.