Opened 4 years ago

Closed 4 years ago

#4720 closed defect (fixed)

FFplay sometimes buffers not enough data for hls

Reported by: rasjani Owned by:
Priority: normal Component: ffplay
Version: git-master Keywords:
Cc: cus@passwd.hu Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

Summary of the bug: audio out of sync when playing ts file
How to reproduce:

$ ffplay http://pcuf.fi/~rasjani/koditest/yletv1_1080p.m3u8

Background:

I've been developing kodi addon for for a service that streams ts files via hls and it seems that their streams can't be played without audio lang with Kodi. I've spent yesterday communicationg and debugging the issue with following findings:

  • streams can be played with web players GrindPlayer?, FlowPlayer? without audio sync issues
  • streams can be played with VLC & QuickTime? (osx 10.8.5) without audio sync issues.
  • Kodi isengard beta1 & beta2 and master nightly build has audio sync issue. Master build is using ffmpeg 2.6.3. Verified that same is happening on OSX and Linux.
  • Standalone ffplay has audio sync issue (tested only with ancient version of 2.3.2, on osx)

I've provided a small clip of example data here so that you can reproduce the issue here: http://www.pcuf.fi/~rasjani/koditest/

Folder contains few .ts files, playlists, my kodi.log and maybe some relevant chatter from #kodi which could point out where the issue actually is.

I was asked to open this bug report against ffmpeg based on irc conversation and discussion on my original bug report here: http://trac.kodi.tv/ticket/16122

This could be a content issue from transcoding the service does but then again, all other players i tried, did not have the issue of audio falling out of sync.

Change History (11)

comment:1 Changed 4 years ago by cehoyos

  • Resolution set to worksforme
  • Status changed from new to closed

I do not see an out-of-sync issue for the sample stream you provided.

Please reopen this ticket if the issue is reproducible for you with current FFmpeg git head (except if you want to report a regression or a security-relevant issue) and if you can provide the FFmpeg command line that allows to reproduce the issue together with the complete, uncut console output.

Generally, please only report issues against ffplay if they are not reproducible with ffmpeg, it is often much harder to reproduce issues with ffplay than with ffmpeg. If this issue is ffplay-only, please say so.

comment:2 Changed 4 years ago by rasjani

  • Resolution worksforme deleted
  • Status changed from closed to reopened

Sample data uploaded to ftp in /Incoming/audio_out_of_sync_example_bug_4720.ts

Can be reproduced with git master with latest commit sha being: fd4c87fa3becaf8a6c480db915daf51e297b76c5

janimikkonen@RASJani ~/src/kodi/ffmpeg (master)$ DYLD_FALLBACK_LIBRARY_PATH=./libavcodec:./libavdevice:./libavfilter:./libavformat:./libavresample:./libavutil:./libpostproc:./libswresample:./libswscale  ./ffplay ./audio_out_of_sync_example_bug_4720.ts
ffplay version N-73635-gfd4c87f Copyright (c) 2003-2015 the FFmpeg developers
  built with Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
  configuration: --enable-shared --enable-pthreads --enable-gpl --enable-version3 --enable-nonfree --enable-hardcoded-tables --enable-avresample --enable-vda --cc=clang --host-cflags= --host-ldflags= --enable-libx264 --enable-libfaac --enable-libmp3lame --enable-libxvid --enable-ffplay
  libavutil      54. 28.100 / 54. 28.100
  libavcodec     56. 47.100 / 56. 47.100
  libavformat    56. 40.100 / 56. 40.100
  libavdevice    56.  4.100 / 56.  4.100
  libavfilter     5. 21.100 /  5. 21.100
  libavresample   2.  1.  0 /  2.  1.  0
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  2.100 /  1.  2.100
  libpostproc    53.  3.100 / 53.  3.100
Input #0, mpegts, from './audio_out_of_sync_example_bug_4720.ts':
  Duration: 00:01:10.41, start: 82088.120000, bitrate: 4170 kb/s
  Program 1
    Stream #0:0[0x101]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc
    Stream #0:1[0x102]: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 84 kb/s
82184.61 A-V:  0.231 fd=1204 aq=    0KB vq=    0KB sq=    0B f=0/0
janimikkonen@RASJani ~/src/kodi/ffmpeg (master)$
Last edited 4 years ago by rasjani (previous) (diff)

comment:3 Changed 4 years ago by rasjani

As said, i opened this bug here on request of few devs in #kodi irc channel because kodi uses ffmpeg to play and atleast *i* can preproduce the issue also with ffplay but not with other players mentioned in the first post.

So, not ffplay bug, just means to reproduce.

comment:4 Changed 4 years ago by cehoyos

The sample you uploaded plays very fine in-sync here with current FFplay, particularly the words 'Iran', "safer" and "Barack Obama" are good testing points imo.

Which version of libsdl are you using? Could this be a performance issue? I would expect this sample to play badly on slow hardware?

comment:5 follow-up: Changed 4 years ago by rasjani

Currently testing osx 10.8.5
Processor: 2.6 Ghz Intel core i5
Memory: 8GB 1600 MHz DDR3
SSD

So i doubt that its a performance issue.

SDL version installed with homebrew and its currently a version 1.2.15

Do you need any other information ? I can be also reached in freenode under a nick "jani"

comment:6 in reply to: ↑ 5 ; follow-up: Changed 4 years ago by cehoyos

Replying to rasjani:

Do you need any other information ?

Yes: I'd like to know why it works for me but not for you.
I can reproduce the issue with xine, and I believe that what FFplay does is much better than what (my old version of) vlc does, but this is certainly a personal decision.

The second question is of course why you believe that the handling of input streams with "missing" audio (see also ticket #4674) is related to the buffering of hls...

comment:7 in reply to: ↑ 6 Changed 4 years ago by rasjani

Replying to cehoyos:

Yes: I'd like to know why it works for me but not for you.
I can reproduce the issue with xine, and I believe that what FFplay does is much better than what (my old version of) vlc does, but this is certainly a personal decision.

Im sorry, i dont know what to say to that. If this is not a bug (somewhere) then its my env in the end and i wouldn't wont to bother anyone with those.

Replying to cehoyos:

The second question is of course why you believe that the handling of input streams with "missing" audio (see also ticket #4674) is related to the buffering of hls...

I don't believe what i don't even know about, sorry. I'm reporting this with my very limited undertanding of video/audio codecs as just an addon developer for kodi who was told by kodi devs to report my findings here. Originally did think that this could be buffering/streaming issue but if the .ts file is on local filesystem, i still get the same issue.

Does that give an answer?

PS. im currently building ffmpeg master on old ubuntu box acting as my main kodi device (the device where my original issue was first noticed after moving to beefier MBP) and i will report back the findings with debug loglevel. anything else i should provide or just close the ticket?

Last edited 4 years ago by rasjani (previous) (diff)

comment:8 Changed 4 years ago by rasjani

On Linux, ffplay (same version as i compiled for osx) - audio is playing fine with alot worse hardware specs for the exact same file.

comment:9 Changed 4 years ago by cehoyos

Please test the current FFplay snapshot from https://evermeet.cx/ffmpeg/ - it works on my osx box with your sample.

comment:10 Changed 4 years ago by cehoyos

  • Component changed from undetermined to ffplay
  • Reproduced by developer set
  • Status changed from reopened to open
  • Summary changed from HLS w/ Transport Stream audio out of sync to FFplay sometimes buffers not enough data for hls
  • Version changed from 2.6.3 to git-master

I was unable to reproduce an issue for the provided sample audio_out_of_sync_example_bug_4720.ts, neither on Linux nor OSX (using evermeet binaries). The file is an excellent sample for ticket #4674.

The issue that not enough data is buffered when reading hls is reproducible with FFplay: I suspect that this has to be fixed in the playback software (transcoding needs no buffering and the library cannot know if you want realtime playback or transcoding) but I may of course miss something.

In no case did I see an A/V sync issue, ffplay just pauses for an instant to load more data.

comment:11 Changed 4 years ago by cus

  • Cc cus@passwd.hu added
  • Resolution set to fixed
  • Status changed from open to closed
Note: See TracTickets for help on using tickets.