Opened 10 years ago
Closed 9 years ago
#4720 closed defect (fixed)
FFplay sometimes buffers not enough data for hls
Reported by: | Jani Mikkonen | 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 by , 10 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
comment:2 by , 10 years ago
Resolution: | worksforme |
---|---|
Status: | closed → 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)$
comment:3 by , 10 years ago
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 by , 10 years ago
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?
follow-up: 6 comment:5 by , 10 years ago
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"
follow-up: 7 comment:6 by , 10 years ago
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 by , 10 years ago
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?
comment:8 by , 10 years ago
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 by , 10 years ago
Please test the current FFplay snapshot from https://evermeet.cx/ffmpeg/ - it works on my osx box with your sample.
comment:10 by , 9 years ago
Component: | undetermined → ffplay |
---|---|
Reproduced by developer: | set |
Status: | reopened → open |
Summary: | HLS w/ Transport Stream audio out of sync → FFplay sometimes buffers not enough data for hls |
Version: | 2.6.3 → 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 by , 9 years ago
Cc: | added |
---|---|
Resolution: | → fixed |
Status: | open → closed |
Fixed in 8628b06b317ee53c09a062c5357343f73a5ea08e.
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.