This is fixed in GIT master and the fixes will all be in 1.3.1 and newer. Unfortunately they can't be easily backported as they required larger refactoring in many different places.

Ah you say you tried git master... as of yesterday night? Because it seems to work well here now except for libav complaining about a broken stream on bitrate switches. Which seems to be caused by the fragments not all starting on a keyframe.

Can you attach a backtrace of the crashes with 1.2.4 btw? Seems to not crash here for me, just does not work very optimal.

The problem with artifacts in http://live.mdragon.org/gearmix/prog_index.m3u8 is that it doesn't conform to the spec. Between the first and second fragment the TS stream is not continuous, and the playlist should have the X-DISCONT (?) marker because of that.

#EXT-X-DISCONTINUITY was the name

sorry
1.2.3 crash

but still
1.3.1 with libav from gst-libav
do not play apple test files
If I mix segments in one hls stream I see artifacts

And
If I put on my server only gear3 and gear4 quality 

#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=484444
gear3/prog_index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=737777
gear4/prog_index.m3u8


player stop after 1 segment
but it still download segments from gear4

apache log
http://pastebin.com/5J07RWts

And in many times if server file is missing
hlsdemux loop forever and download files forever from start.
http://pastebin.com/V0R0hv2V

commit b891bd04d50424410c43865f30150e3553f84b59
Author: Thiago Santos <ts.santos@sisa.samsung.com>
Date:   Mon May 5 11:13:09 2014 -0300

    hlsdemux: Only set the segment position if there is a timestamp
    
    Only the first buffer of a fragment has its timestamp set, so only
    update the segment.position when pushing those buffers to avoid
    having GST_CLOCK_TIME_NONE set to the position
    
    https://bugzilla.gnome.org/show_bug.cgi?id=729364


This solves the infinite loop getting a fragment that doesn't exist

So what's left here?

there are still distortion in video
GST_DEBUG="hlsdemux:5" gst-launch-1.0 playbin uri="http://live.mdragon.org/gearmix2/prog_index.m3u8"

fileSequence0.ts"
has different resolution then 
fileSequence1.ts"

fileSequence1.ts" really start with SPS and PPS
so no reason for video distortion

I use gstreamer 1.3.2 from
https://launchpad.net/~ricotz/+archive/experimental?field.series_filter=trusty
and gst-libav with static libav

It looks like something that feed codecparsers_h264 break data
http://pastebin.com/AnUtDHj7

As if I play files separatly there isn't any problems

That probably means that on DISCONT one of the elements used here drops more data than it would at the beginning of the stream... too much data.

infinite download of nonexistent fragments is still there

GST_DEBUG="hlsdemux:5" gst-launch-1.0 playbin uri="http://devimages.apple.com/iphone/samples/bipbop/bipbopall.m3u8"

gstreamer git branche from 20140529
1.3.2.1+git20140529.07919d87-0ubuntu1~14.04~ricotz0
https://launchpad.net/~ricotz/+archive/experimental?field.series_filter=trusty

Created attachment 277940 [details] [review]
tsdemux don't drop whole buffer if continuity counter don't match

This patch fix distortion that came if fragment quality change.

I can add property to force checking continuity counter.
What do you think?
for example libav do warning in their ts parser

tsdemux drop whole buffer if continuity counter don't match.

This patch fix distortion that came if fragment quality change.

I can add property to force checking continuity counter.
What do you think?
for example libav do warning in their ts parser

Hm, it should only drop the current incomplete MPEGTS packet there, not a complete buffer.

tsdemux should not complain about the continuity counter mismatching if there is a discont marked between the two fragments, as Sebastian suggested in comment #5

Have you added #EXT-X-DISCONTINUITY to your m3u8 file?

Comment on attachment 277940 [details] [review]
tsdemux don't drop whole buffer if continuity counter don't match

No

close this bug