[FFmpeg-user] A/V sync problems with h264/aac video fragment
Konrad Karl
kk_konrad at gmx.at
Fri Apr 13 17:18:43 CEST 2012
On Fri, Apr 13, 2012 at 02:15:27PM +0000, Carl Eugen Hoyos wrote:
> Konrad Karl <kk_konrad <at> gmx.at> writes:
>
> > I am experiencing A/V sync issue with one of my movies rendered
> > with kdenlive (1080p50 H264 25Mbit/s / AAC 384 kbit/s mp4)
>
> If you want to report a problem with ffmpeg, please provide the
> ffmpeg command line you are using together with complete, uncut
> console output.
> If you have a problem with ffplay that is not reproducible with
> ffmpeg, please explain that and add complete uncut ffplay
> console output.
This is a bit difficult since there was not any ffmpeg console command
involved to produce the movie (but the MLT framework uses ffmpeg
internally) so I was trying this mailing list as I have the impression
that the experts are listening here.
The kdenlive render shell script:
#! /bin/sh
SOURCE="/home/konrad/india/kdenlive/scripts/t6-4-h264.sh.mlt"
TARGET="file:///home/konrad/india/h264/t6-4.mp4"
RENDERER="/home/konrad/kdenlive/20120318/bin/kdenlive_render"
MELT="/home/konrad/kdenlive/20120318/bin/melt"
PARAMETERS="-pid:6256 in=0 out=26830 $MELT atsc_1080p_50 avformat - $SOURCE $TARGET f=mp4 hq=1 acodec=aac ab=384k ar=48000 pix_fmt=yuv420p vcodec=libx264 minrate=0 vb=25000k g=250 bf=3 b_strategy=1 subcmp=2 cmp=2 coder=1 flags=+loop flags2=dct8x8 qmax=51 subq=7 qmin=10 qcomp=0.6 qdiff=4 trellis=1 aspect=@16/9 pass=1 threads=2 real_time=-1"
$RENDERER $PARAMETERS
ffplay uses around 30..70 % CPU while playing the sample. I hit the
enter key several times to show how the A/V offset increases.
(Intel Core i3 @ 3 GHz, 2 cores)
mplayer takes 3..6 % cpu due to VDPAU
Stuttering starts at about 00:10 - pls see the movie fragment:
A/V offset builds up as soon as the white elephant is visible.
Over one hour of movies have been produced the same way and they all
play fine with millisecond A/V offset with the exception of this
~ 30 second range in the last movie .....
ffplay test1.mp4
ffplay version N-34018-ge9dc616 Copyright (c) 2003-2012 the FFmpeg developers
built on Apr 13 2012 10:26:36 with gcc 4.6.3 20120306 (Red Hat 4.6.3-2)
configuration: --prefix=/home/ki/kdenlive/20120413 --disable-doc --disable-network --disable-ffserver --enable-gpl --enable-version3 --enable-shared --enable-debug --disable-stripping --enable-pthreads --enable-runtime-cpudetect --enable-vdpau --enable-libtheora --enable-libvorbis --enable-libmp3lame --enable-libx264 --enable-libvpx
libavutil 51. 46.100 / 51. 46.100
libavcodec 54. 14.101 / 54. 14.101
libavformat 54. 3.100 / 54. 3.100
libavdevice 53. 4.100 / 53. 4.100
libavfilter 2. 69.101 / 2. 69.101
libswscale 2. 1.100 / 2. 1.100
libswresample 0. 11.100 / 0. 11.100
libpostproc 52. 0.100 / 52. 0.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'zz2.mp4':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf54.3.100
Duration: 00:00:18.17, start: 0.000000, bitrate: 61384 kb/s
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 61163 kb/s, 50 fps, 50 tbr, 50 tbn, 100 tbc
Metadata:
handler_name : VideoHandler
Stream #0:1(und): Audio: aac (mp4a / 0x6134706D), 48000 Hz, stereo, s16, 332 kb/s
Metadata:
handler_name : SoundHandler
1.42 A-V: -0.003 fd= 30 aq= 11KB vq= 1KB sq= 0B f=0/0 f=0/0
1.77 A-V: -0.007 fd= 30 aq= 12KB vq= 100KB sq= 0B f=0/0
2.22 A-V: 0.002 fd= 30 aq= 11KB vq= 633KB sq= 0B f=0/0
2.77 A-V: -0.008 fd= 30 aq= 11KB vq= 596KB sq= 0B f=0/0
3.29 A-V: -0.007 fd= 30 aq= 11KB vq= 419KB sq= 0B f=0/0
3.86 A-V: -0.003 fd= 30 aq= 10KB vq= 3KB sq= 0B f=0/0
4.38 A-V: -0.001 fd= 30 aq= 11KB vq= 2KB sq= 0B f=0/0
4.94 A-V: 0.002 fd= 30 aq= 9KB vq= 1KB sq= 0B f=0/0
5.45 A-V: -0.011 fd= 30 aq= 10KB vq= 1KB sq= 0B f=0/0
6.05 A-V: -0.006 fd= 30 aq= 11KB vq= 1KB sq= 0B f=0/0
6.69 A-V: -0.005 fd= 30 aq= 11KB vq= 1KB sq= 0B f=0/0
7.21 A-V: -0.008 fd= 30 aq= 11KB vq= 1KB sq= 0B f=0/0
7.82 A-V: 0.002 fd= 30 aq= 10KB vq= 1KB sq= 0B f=0/0
8.46 A-V: -0.005 fd= 30 aq= 10KB vq= 1KB sq= 0B f=0/0
9.05 A-V: -0.007 fd= 30 aq= 11KB vq= 456KB sq= 0B f=0/0
9.57 A-V: -0.013 fd= 30 aq= 12KB vq= 1627KB sq= 0B f=0/0
10.08 A-V: 0.064 fd= 37 aq= 6KB vq= 1884KB sq= 0B f=0/0
10.65 A-V: 0.209 fd= 58 aq= 5KB vq= 2994KB sq= 0B f=0/0
11.20 A-V: 0.288 fd= 81 aq= 5KB vq= 4228KB sq= 0B f=0/0
11.74 A-V: 0.365 fd= 105 aq= 5KB vq= 5271KB sq= 0B f=0/0
12.30 A-V: 0.494 fd= 127 aq= 5KB vq= 6988KB sq= 0B f=0/0
12.90 A-V: 0.597 fd= 152 aq= 5KB vq= 7802KB sq= 0B f=0/0
13.49 A-V: 0.685 fd= 176 aq= 5KB vq= 9334KB sq= 0B f=0/0
14.01 A-V: 0.772 fd= 197 aq= 5KB vq=11381KB sq= 0B f=0/0
14.59 A-V: 0.909 fd= 221 aq= 5KB vq=13131KB sq= 0B f=0/0
15.19 A-V: 1.022 fd= 245 aq= 6KB vq=14916KB sq= 0B f=0/0
15.78 A-V: 1.120 fd= 270 aq= 4KB vq=15539KB sq= 0B f=0/0
16.37 A-V: 1.202 fd= 295 aq= 0KB vq=15513KB sq= 0B f=0/0
16.78 A-V: 1.122 fd= 319 aq= 0KB vq=15370KB sq= 0B f=0/0
17.16 A-V: 1.051 fd= 342 aq= 0KB vq=15379KB sq= 0B f=0/0
17.58 A-V: 1.053 fd= 363 aq= 0KB vq=15376KB sq= 0B f=0/0
17.91 A-V: 0.943 fd= 385 aq= 1KB vq=15554KB sq= 0B f=0/0
18.43 A-V: 1.117 fd= 402 aq= 0KB vq=12795KB sq= 0B f=0/0
19.06 A-V: 1.301 fd= 423 aq= 0KB vq= 5339KB sq= 0B f=0/0
19.67 A-V: 1.368 fd= 443 aq= 0KB vq= 0KB sq= 0B f=0/0
20.28 A-V: 1.368 fd= 443 aq= 0KB vq= 0KB sq= 0B f=0/0
20.85 A-V: 1.368 fd= 443 aq= 0KB vq= 0KB sq= 0B f=0/0
21.46 A-V: 1.368 fd= 443 aq= 0KB vq= 0KB sq= 0B f=0/0
22.09 A-V: 1.368 fd= 443 aq= 0KB vq= 0KB sq= 0B f=0/0
22.91 A-V: 1.368 fd= 443 aq= 0KB vq= 0KB sq= 0B f=0/0
23.79 A-V: 1.368 fd= 443 aq= 0KB vq= 0KB sq= 0B f=0/0
24.49 A-V: 1.368 fd= 443 aq= 0KB vq= 0KB sq= 0B f=0/0
25.40 A-V: 1.368 fd= 443 aq= 0KB vq= 0KB sq= 0B f=0/0
> I suspect you are seeing a performance issue.
As explained above I dont think so. (I might be wrong of course:)
> > Sorry for the long post but H264 looks definitely better
> > than mp4 ASP.
>
> That is not true as such, or in other words:
> There certainly is a (high) bit-rate that allows very similar
> quality between any (sane) codecs, esp. MPEG-2 / ASP / H264.
It is true for some scenes of my movie, especially fine structures
e.g. leaves of a tree and such contain much more detail in H264
(perhaps the ASP parameters of kdenelive are not optimal) and the
difference is quite visible once one knows where to look at..
I would appreciate getting more insight what might be wrong here.
Konrad
> Carl Eugen
More information about the ffmpeg-user
mailing list