#`EXTINF` goes backwards, `?index=` never changes

1 messages · Page 1 of 1 (latest)

shut briar
#

I'm having an issue with the HLS Direct method on playing some random movies and tv episodes.

It seems that the segment/index never really finishes for some files.

What I mean, for example, a currently playing movie:

# curl "https://etv01/iptv/channel/2461.m3u8?mode=hls-direct"
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:110
#EXT-X-DISCONTINUITY
#EXTINF:2252.68,
https://etv01/ffmpeg/stream/2461?index=110&mode=hls-direct

Many seconds later:

# curl "https://etv01/iptv/channel/2461.m3u8?mode=hls-direct"
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:110
#EXT-X-DISCONTINUITY
#EXTINF:1953.81,
https://etv01/ffmpeg/stream/2461?index=110&mode=hls-direct

Notice how the EXTINF tag decreases, but we're still at the same EXT-X-MEDIA-SEQUENCE

This is causing some issues -- mainly another running ffmpeg that processes the output of Etv won't ever finish/write the segment list.

This is on 0.8.8-6c4f63ad-docker-nvidia -- again, there's no transcoding taking place.

I'm not entirely sure what generates the m3u8 inside Etv, but I'm feeling there's an issue with detecting segment durations properly here.

vital elm
#

hls direct doesnt segment anything

#

there is one segment

#

extinf tells the duration of the segment

#

so if you load the playlist later, the duration should be smaller

shut briar
#

well, yeah, but shouldn't the index reflect that? I'm seeing different indexes for other channels/videos, as in, they are actually updating?

#

or am I tripping?

#

Maybe I'm not explaining it properly, for most channels, this works great:

# ffmpeg -i "https://etv01/iptv/channel/602.m3u8?mode=hls-direct" -c copy -f hls out.m3u8
[...]
[hls @ 0x5e40d9e42a80] Opening 'out0.ts' for writing0:00.00 bitrate=N/A speed=N/A
[hls @ 0x5e40d9e42a80] Opening 'out.m3u8.tmp' for writing
[hls @ 0x5e40d9e42a80] Opening 'out1.ts' for writing bitrate=N/A speed= 2.1x
[hls @ 0x5e40d9e42a80] Opening 'out.m3u8.tmp' for writing
[hls @ 0x5e40d9e42a80] Opening 'out2.ts' for writing bitrate=N/A speed= 1.6x
[hls @ 0x5e40d9e42a80] Opening 'out.m3u8.tmp' for writing
[hls @ 0x5e40d9e42a80] Opening 'out3.ts' for writing bitrate=N/A speed= 1.4x
[...]
#

For some, well, not so much:

[hls @ 0x603a890f9800] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
[mpegts @ 0x603a89158980] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
frame=  290 fps= 27 q=-1.0 size=N/A time=00:00:12.13 bitrate=N/A speed=1.11x
#

like, there's no segment detection from the other ffmpeg, and I'm not sure what's causing this

vital elm
#

i think index is used for rolling over from one item to the next, kind of trying to get clients to see new items as a new segment

shut briar
#

Ah, I see, ok, so I'm looking at the wrong thing then

vital elm
#

there are no segments in hls direct - all it does is change the container

shut briar
#

can't figure out why the hell some channels/files aren't working properly