Too many seek by media playback

[Igor Selivanov]

Summary of the bug:

During media playback FFMPEG seeks in media format that causes TCP connection break. As result download speed is going down. In some cases download speed is slower than playback that cause playback interruption.

This behavior is depended on media file format. Please find below TV recording from one of the Swiss HbbTV provider.

Two files are available unter:

​https://cloud.loewe.de/index.php/s/Q3TGf73Jyqz5P10
​https://cloud.loewe.de/index.php/s/9QoEPe7lfsVTZjW

How to reproduce:

ffplay -v verbose https://cloud.loewe.de/index.php/s/9QoEPe7lfsVTZjW/download

or

ffplay -v verbose -i https://cloud.loewe.de/index.php/s/Q3TGf73Jyqz5P10/download

Output shows periodically new TCP connections:

....
[tcp @ 0x7fc2dc8d47c0] Starting connection attempt to 10.12.20.175 port 443
[tcp @ 0x7fc2dc8d47c0] Successfully connected to 10.12.20.175 port 443
....

Playback as file (not over network) reports too many seeks. FFMPEG reports aprox. 100 seeks per second.

ffplay -v verbose da7b519f-f209-42a4-9de7-9c67b12b1059_P6.mp4

After 10 seconds playback

....
AVIOContext @ 0x7f5060009bc0] Statistics: 36594017 bytes read, 1025 seeks

Converting this file (with codec copy) fix "seek" problem:

ffmpeg -i da7b519f-f209-42a4-9de7-9c67b12b1059_P6.mp4 -c:v copy output.mp4

What is wrong in this format? Is it related to Wowza Media Server Pro transcoding approach? Can you please look at this.

Thanks in advance

[Tomas Härdin]

Well, take a look at the way the packets in the file are ordered:

$ wget https://cloud.loewe.de/index.php/s/9QoEPe7lfsVTZjW/download
$ ffprobe -show_packets download | egrep "stream|pos" | head -n200 | tail -n8
[...]
stream_index=0
pos=480382
stream_index=1
pos=729963
stream_index=0
pos=482332
stream_index=1
pos=730315

Compared to a remuxed file:

stream_index=1
pos=337372
stream_index=0
pos=337735
stream_index=1
pos=375978
stream_index=0
pos=376350

So yes, Wowza seems to be producing not-so-good files. But since remuxing the files fixes this, you could just always do that. I'd suggest reporting this to Wowza, or dropping them entirely.

[Igor Selivanov]

I understand that remuxing of the file fix this problem. Unfortunately files are pretty big and available only for streaming (from HbbTV service). It's seems that "seeking" behavior is happening only with FFMPEG, for example Gstreamer doesn't break TCP connection. I also understand that format is not optimal, but also not wrong, please correct me if I am wrong.

My question: is it possible to demux (not remux) this file format without seeking (new TCP connection)? Is any workaround possible?

Thanks in advance.

[Carl Eugen Hoyos]

I believe this is a duplicate of #7592