Opened 5 years ago

Closed 5 years ago

#7891 closed defect (duplicate)

Too many seek by media playback

Reported by: Igor Selivanov Owned by:
Priority: normal Component: undetermined
Version: unspecified Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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

Change History (5)

comment:1 by Tomas Härdin, 5 years ago

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.

comment:2 by Carl Eugen Hoyos, 5 years ago

Resolution: invalid
Status: newclosed

comment:3 by Igor Selivanov, 5 years ago

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.

comment:4 by Igor Selivanov, 5 years ago

Resolution: invalid
Status: closedreopened

comment:5 by Carl Eugen Hoyos, 5 years ago

Resolution: duplicate
Status: reopenedclosed

I believe this is a duplicate of #7592

Note: See TracTickets for help on using tickets.