Probably closely related to http://avidemux.org/smif/index.php/topic,16994.0.html (http://avidemux.org/smif/index.php/topic,16994.0.html): The attached text file contains a link to a 170 MiB long transport stream fragment uploaded to WeTransfer. This testcase contains a h264 HD video and 4 audio tracks including an ac3 one (stream id 6) with the number of channels changing midway.
Avidemux fails to play this testcase properly as it wrongly assumes that it can safely halve the framerate:
[checkForDoubledFps] Checking for doubled FPS.., time increment ceiling = 18000
[checkForDoubledFps] Checking DTS...
[checkTiming] Good : 3080
[checkTiming] Bad : 0
[checkForDoubledFps] Checking PTS...
[checkTiming] Good : 4596
[checkTiming] Bad : 0
[checkForDoubledFps] We can safely halve fps
[addFile] Halving Fps...
When Avidemux saves the testcase in copy mode as mkv and the ac3 audio track is included (especially as the only audio track), both ffplay and mplayer stop playing audio at the point of the channel layout switch, mplayer showing audio timestamps not advancing from that moment on.
ffprobe reports:
ffprobe -report testcase-ac3-framerate-issue.ts
ffprobe version 3.0.2 Copyright (c) 2007-2016 the FFmpeg developers
built with gcc 6.1.1 (GCC) 20160621 (Red Hat 6.1.1-3)
configuration: --prefix=/usr --bindir=/usr/bin --datadir=/usr/share/ffmpeg --incdir=/usr/include/ffmpeg --libdir=/usr/lib64 --mandir=/usr/share/man --arch=x86_64 --optflags='-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic' --enable-bzlib --disable-crystalhd --enable-fontconfig --enable-frei0r --enable-gcrypt --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libcdio --enable-indev=jack --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libmp3lame --enable-openal --enable-opencl --enable-libopencv --enable-opengl --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libv4l2 --enable-libvpx --enable-libx264 --enable-libx265 --enable-x11grab --enable-avfilter --enable-avresample --enable-postpr libavutil 55. 17.103 / 55. 17.103
libavcodec 57. 24.102 / 57. 24.102
libavformat 57. 25.100 / 57. 25.100
libavdevice 57. 0.101 / 57. 0.101
libavfilter 6. 31.100 / 6. 31.100
libavresample 3. 0. 0 / 3. 0. 0
libswscale 4. 0.100 / 4. 0.100
libswresample 2. 0.101 / 2. 0.101
libpostproc 54. 0.100 / 54. 0.100
[file @ 0x107af40] Setting default whitelist 'file,crypto'
[mpegts @ 0x107a7c0] Format mpegts probed with size=2048 and score=100
[mpegts @ 0x107a7c0] stream=0 stream_type=5 pid=4f6 prog_reg_desc=
[mpegts @ 0x107a7c0] stream=1 stream_type=1b pid=13f7 prog_reg_desc=
[mpegts @ 0x107a7c0] stream=2 stream_type=3 pid=13f8 prog_reg_desc=
[mpegts @ 0x107a7c0] stream=3 stream_type=3 pid=13f9 prog_reg_desc=
[mpegts @ 0x107a7c0] stream=4 stream_type=6 pid=13fa prog_reg_desc=
[mpegts @ 0x107a7c0] stream=5 stream_type=6 pid=13fb prog_reg_desc=
[mpegts @ 0x107a7c0] stream=6 stream_type=6 pid=13fc prog_reg_desc=
[mpegts @ 0x107a7c0] stream=7 stream_type=3 pid=13fd prog_reg_desc=
[mpegts @ 0x107a7c0] stream=8 stream_type=6 pid=13fe prog_reg_desc=
[mpegts @ 0x107a7c0] stream=9 stream_type=6 pid=13ff prog_reg_desc=
[mpegts @ 0x107a7c0] Before avformat_find_stream_info() pos: 0 bytes read:458752 seeks:1
[mpegts @ 0x107a7c0] parser not found for codec none, packets or times may be invalid.
[mpegts @ 0x107a7c0] parser not found for codec dvb_teletext, packets or times may be invalid.
[mpegts @ 0x107a7c0] parser not found for codec dvb_teletext, packets or times may be invalid.
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] decode_slice_header error
[h264 @ 0x109d340] no frame!
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] decode_slice_header error
[h264 @ 0x109d340] no frame!
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] decode_slice_header error
[h264 @ 0x109d340] no frame!
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] decode_slice_header error
[h264 @ 0x109d340] no frame!
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] decode_slice_header error
[h264 @ 0x109d340] no frame!
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] decode_slice_header error
[h264 @ 0x109d340] no frame!
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] decode_slice_header error
[h264 @ 0x109d340] no frame!
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] decode_slice_header error
[h264 @ 0x109d340] no frame!
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] decode_slice_header error
[h264 @ 0x109d340] no frame!
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] decode_slice_header error
[h264 @ 0x109d340] no frame!
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] decode_slice_header error
[h264 @ 0x109d340] no frame!
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] decode_slice_header error
[h264 @ 0x109d340] no frame!
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] decode_slice_header error
[h264 @ 0x109d340] no frame!
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] decode_slice_header error
[h264 @ 0x109d340] no frame!
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] decode_slice_header error
[h264 @ 0x109d340] no frame!
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] decode_slice_header error
[h264 @ 0x109d340] no frame!
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] decode_slice_header error
[h264 @ 0x109d340] no frame!
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] decode_slice_header error
[h264 @ 0x109d340] no frame!
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] non-existing PPS 0 referenced
[h264 @ 0x109d340] decode_slice_header error
[h264 @ 0x109d340] no frame!
[h264 @ 0x109d340] Frame num gap 6 1
[h264 @ 0x109d340] Frame num gap 6 2
[h264 @ 0x109d340] Frame num gap 6 3
[h264 @ 0x109d340] Frame num gap 6 4
[h264 @ 0x109d340] no picture ooo
[h264 @ 0x109d340] Increasing reorder buffer to 2
[h264 @ 0x109d340] no picture ooo
[h264 @ 0x109d340] no picture ooo
[h264 @ 0x109d340] no picture ooo
[h264 @ 0x109d340] no picture ooo
[h264 @ 0x109d340] no picture ooo
[h264 @ 0x109d340] no picture ooo
[h264 @ 0x109d340] no picture
[h264 @ 0x109d340] no picture
[mpegts @ 0x107a7c0] Probe buffer size limit of 5000000 bytes reached
[NULL @ 0x109fe60] start time for stream 5 is not set in estimate_timings_from_pts
[NULL @ 0x10a2260] start time for stream 8 is not set in estimate_timings_from_pts
[NULL @ 0x10a2e20] start time for stream 9 is not set in estimate_timings_from_pts
[mpegts @ 0x107a7c0] PES packet size mismatch
[mpegts @ 0x107a7c0] PES packet size mismatch
[mpegts @ 0x107a7c0] PES packet size mismatch
[mpegts @ 0x107a7c0] PES packet size mismatch
[mpegts @ 0x107a7c0] PES packet size mismatch
[mpegts @ 0x107a7c0] Could not find codec parameters for stream 0 (Unknown: none ([5][0][0][0] / 0x0005)): unknown codec
Consider increasing the value for the 'analyzeduration' and 'probesize' options
[mpegts @ 0x107a7c0] After avformat_find_stream_info() pos: 0 bytes read:6082704 seeks:3 frames:946
Input #0, mpegts, from 'testcase-ac3-framerate-issue.ts':
Duration: 00:02:05.98, start: 76453.944456, bitrate: 11319 kb/s
Program 10301
Program 10302
Stream #0:0[0x4f6], 0, 1/90000: Unknown: none ([5][0][0][0] / 0x0005)
Stream #0:1[0x13f7], 190, 1/90000: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 50 fps, 50 tbr, 90k tbn, 100 tbc
Stream #0:2[0x13f8](deu), 152, 1/90000: Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, s16p, 192 kb/s
Stream #0:3[0x13f9](fra), 152, 1/90000: Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, s16p, 192 kb/s
Stream #0:4[0x13fa](deu), 188, 1/90000: Subtitle: dvb_teletext ([6][0][0][0] / 0x0006)
Stream #0:5[0x13fb](deu), 0, 1/90000: Subtitle: dvb_subtitle ([6][0][0][0] / 0x0006) (hearing impaired)
Stream #0:6[0x13fc](mul), 112, 1/90000: Audio: ac3 ([6][0][0][0] / 0x0006), 48000 Hz, 5.1(side), fltp, 448 kb/s
Stream #0:7[0x13fd](mis), 152, 1/90000: Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, s16p, 192 kb/s
Stream #0:8[0x13fe](fra), 0, 1/90000: Subtitle: dvb_subtitle ([6][0][0][0] / 0x0006)
Stream #0:9[0x13ff](deu), 0, 1/90000: Subtitle: dvb_subtitle ([6][0][0][0] / 0x0006)
Program 10303
Program 10304
Unsupported codec with id 0 for input stream 0
detected 2 logical cores
Unsupported codec with id 94215 for input stream 4
[AVIOContext @ 0x10831a0] Statistics: 6082704 bytes read, 3 seeks
Avidemux can handle the content of the testcase fine once it has been remuxed e.g. into mkv with ffmpeg using appropriate -map options.
ffplay plays this file fine, no matter which audio track.
saved in copy mode as mkv and the ac3 audio track as the only audio track.
Files (96.5 MB total) ArteHDtestcase-ac3-framerate-issue.mkv
Will be deleted on 4 September, 2016
Download link : https://we.tl/OaQsBZ6gH5
saved the your testvideo and could not find the issue with todays build
bc4c29c [build/clang] Try other alignment workarounds
plays fine in VLC 2.1.6 (Rincewind) and Videos 3.10.1, can you check if the issue is still there with ffplay and mplayer.
Quotestop playing audio at the point of the channel layout switch
I can't follow this? as there is only 1 track (ac3 audio track as the only audio track)
Editor] B- frame possible with that codec
[addFile] [Editor] This is H264, check if we can fill missing PTS
[ADM_setH264MissingPts] We have 0 missing PTS
[checkForDoubledFps] Checking for doubled FPS.., time increment ceiling = 18000
[checkForDoubledFps] Checking DTS...
[checkTiming] Good : 4144
[checkTiming] Bad : 0
[checkForDoubledFps] Checking PTS...
[checkTiming] Good : 6212
[checkTiming] Bad : 0
[checkForDoubledFps] We can safely halve fps
[addFile] Halving Fps...
[renderDisplayResize] Render to 1280x720 zoom=2, old one =0 x 0, zoom=2, render=(nil)
[init] [Vdpau]Xv start
[mixerCreate] Creating vdpauMixer with width=1280, height=720 color=0
[mixerCreate] Vdpau Mixer : Enabling 0 features
[spawnRenderer] VDPAU init ok
Thank you.
Are you able to play the testcase in Avidemux with audio and video in sync? I'm not. Avidemux believes that FPS of the video should be half of the correct value, resulting in a slow motion video and audio going more and more ahead of the video (best seen once the conductor enters the stage). This would be issue no. 1.
Now to issue no. 2:
I don't use VLC, but totem (GNOME Videos) exposes the same issue as mplayer and ffplay when playing the mkv file you generated: from 50.2 seconds into the video on, the sound stops, video continues. In the terminal window where mplayer was lauched, one can watch the audio timestamp remaining frozen at 50.2 while the video timestamp keeps advancing. This is the moment the channel layout in the ac3 track changes.
Quote from: Jan GruuthuseI can't follow this? as there is only 1 track (ac3 audio track as the only audio track)
An ac3 audio track can have different channel layouts. Both stereo (2ch: left and right) and a sort of a surround sound (
https://en.wikipedia.org/wiki/5.1_surround_sound) are common.
Maybe I'm wrong attributing AV async in Avidemux to the halving of FPS, the inability to play this TS in Avidemux with audio and video in sync would have another cause then.
Loading your mkv with the remuxed stream (h264 video + ac3 audio) in Avidemux confirms that there is really no audio data past 50.256, the console gets flooded with messages
[getPacket] AudioGetPacket failed, audioSegment=0
[getPacket] ..and this is the last segment
[refillPacketBuffer] End of audio
[getPCMPacket] [Editor] Cannot refill audio
[fillIncomingBuffer] [Bridge] End of stream
[getPacket] AudioGetPacket failed, audioSegment=0
[getPacket] ..and this is the last segment
the last two lines repeating till the end of the video.
Strange very strange.
@50116 is something strange going on, it is present in the original recording too, you hear the sound drop.
@51396 make here your start and save from here: you have the audio.
Files (57.6 MB total) 51396.mkv
Will be deleted on 4 September, 2016
Download link https://we.tl/zV2CbYF2Qo
see attached screenshots from avidemux saving started only AC-3 selected in avidemux
@ 50.116 2 channels / 6 channels, AC-3
@ 50.786 6 channels, AC-3
@ 51.396 2 channels / 6 channels, AC-3
2 different tracks in one AC3 audio stream?
Beyond my user experience, perhaps mean can see what is going on there.
the thing is with TS you are allowed to change streams on the fly
6 channels -> stereo, maybe even AC3->MP2
But avidemux will sync on the 1st one it finds
So it might be that the stream switches to MP2 and so it cannot find AC3 header
Or something similar, just a thought
I make a test recording tonight from arteHD (dvb-s2) "00:00 Thomas Hampson und Martin Grubinger in Concert" and see tomorrow if the same is going on.
Thank you, could Avidemux maybe deal with similar channel layout switches in TS more graciously? They happen in DVB-S (don't know about DVB-S2) streams by Arte quite often. If I first use ffmpeg to remux the stream into a mkv
ffmpeg -i testcase-ac3-framerate-issue.ts -map 0:1 -map 0:6 -c copy testcase-ac3-framerate-issue-ffmpeg-remuxed.mkv
and then cut "testcase-ac3-framerate-issue-ffmpeg-remuxed.mkv" with Avidemux in copy mode, the audio is fine.
By the way, what do you think about the slow motion playback of the testcase with large and further growing A-V offset in Avidemux? As stated above, ffplay manages to play the stream without issues.
I hope that my sample TS file will help to find out what is really going on here.
Astra 19.2Ã,°E
10743.75 H 51 Astra 1M (DVB-S) <= are you recording from this one?
11493.75 H 19 Pan Europe (DVB-S2) <= I'm using this one, with dvb-s2 STB (openpli)
Quote from: Jan Gruuthuse on August 28, 2016, 07:17:22 PM
Astra 19.2Ã,°E
10743.75 H 51 Astra 1M (DVB-S) <= are you recording from this one?
Yes, from Astra, but the transponder should be 10729 MHz, and it turns out to be DVB-S2 :-o
Anyway, I'm really curious what actually happens in the TS at the spot where Avidemux cuts off the ac3 track.
1st test does not confirm the issue.
Avidemux cut: program change to start concert, ac3 channel only.
Files (68.6 MB total) ArteHDac3test.mkv
Will be deleted on 5 September, 2016
Download link: https://we.tl/eAwGemw4nK
take note:
2 channels / 6 channels, AC-3 is not showing in the saved avidemux edit. see attached artehdac3.png.
I suspect a hardware recording issue? I would like to do a simultaneous recording test, but 1st you should check your STB and rescan the concerned transponders and make a new test recording. If that fails we can discuss how to proceed with simultaneous recording test.
Quote from: eumagga0x2a on August 28, 2016, 08:42:28 PM
Yes, from Astra, but the transponder should be 10729 MHz, and it turns out to be DVB-S2 :-o
That should not be the case?
10729 MHz V on 19.2Ã,°E is a pay TV transponder used by provider "Movistar+ (Astra)"
Current arte transponders see green highlighted:
arte:
(https://avidemux.org/smif/proxy.php?request=http%3A%2F%2Fimg5.fotos-hochladen.net%2Fuploads%2Fartesd10749hlme5y6nr8f.jpg&hash=3a119b0271396d744b28aaffb79fe460324a2241)
ArteHD:
(https://avidemux.org/smif/proxy.php?request=http%3A%2F%2Fimg5.fotos-hochladen.net%2Fuploads%2Fartehd11493hxdhy71n3q8.jpg&hash=43843a7c58b86d6c3fd465ba4736629be4dde401)
Quote from: Jan Gruuthuse on August 29, 2016, 04:35:47 AM
1st test does not confirm the issue.
Avidemux cut: program change to start concert, ac3 channel only.
Files (68.6 MB total) ArteHDac3test.mkv
Thank you, though the source transport stream would have been preferable. Maybe arte HD was doing something terrible earlier but solved the problem on their part now? Your remuxed sample is impeccable.
QuoteI suspect a hardware recording issue? I would like to do a simultaneous recording test, but 1st you should check your STB and rescan the concerned transponders and make a new test recording. If that fails we can discuss how to proceed with simultaneous recording test.
I'll check it even if I don't think there was anything wrong with the hardware as apart from the ac3 audio issue exclusively at the beginning of some (but important for me) music programs on arte HD there were no problems like garbled data or drop-outs with the recorded streams. The next opportunity will arise next Sunday.
If it turns out that arte HD now avoids to trigger the issue in Avidemux, it reduces the urgency for me to pursue a solution on Avidemux part, sure (not mentioning that I was not aware of a workaround via ffmpeg till the day before yesterday). But it doesn't change anything for the better for people who would need a solution in Avidemux. The question is simply whether Mean finds it worth an effort to dig into the matter or not.
QuoteQuote from: eumagga0x2a on August 28, 2016, 08:42:28 PM
Yes, from Astra, but the transponder should be 10729 MHz, and it turns out to be DVB-S2 :-o
That should not be the case?
10729 MHz V on 19.2Ã,°E is a pay TV transponder used by provider "Movistar+ (Astra)"
My apologies, I've taken "Test Transponder-Frequenz" for Astra 19.2 in the LNB settings which is listed as 10729 MHz for the arte HD (DVB-S2!) transponder which is really 11494 MHz on Astra 19.2.
Again, I think that removing arte HD from the list of offenders who do things Avidemux doesn't like definitely helps me (thank you), but doesn't help with improving Avidemux.
Quote from: eumagga0x2a on August 29, 2016, 04:39:59 PMThank you, though the source transport stream would have been preferable
The source transport stream recording is nearly 9 GB, will try to make a clean cut (same video part used to test.)
QuoteMaybe arte HD was doing something terrible earlier but solved the problem on their part now? Your remuxed sample is impeccable.
Arte sits within public German broadcasts. I'm using these for years now (weekly, ...). Only issues I've come across are transmissions interruptions,breaks (weather, plane, ...)
QuoteI'll check it even if I don't think there was anything wrong with the hardware
Could be the software on that hardware. Like firmware update (flash) or Linux updates (OpenPLi, ...)
QuoteAgain, I think that removing arte HD from the list of offenders who do things Avidemux doesn't like definitely helps me (thank you), but doesn't help with improving Avidemux.
This open for debate: If the input source is wrong? How far could/would you go without compromising the good input sources by trying to fix bad input source video within Avidemux.
If you find you still have ArteHD issues, we could agree to make the same recording at the same time. If the channel stream has a difference, one of the receivers does change something while recording and that should not be the case/happening.
Think I got close enough with the cut (1.2 Gb dropped in front):
File (127 MB total) AC3UsedFootage.ts
Will be deleted on 6 September, 2016
Download link: https://we.tl/4gphxZcwfc
ac3 is the 3rd track. Switch this to 1st track see attached:
Thank you, this was very helpful.
Can you please confirm that...
1) ...Avidemux is unable to play AC3UsedFootage.ts file with AV in sync?
2) when the ac3 track is set as the very first or the only audio track and in "Local playback downmixing" "No downmixing" is selected, only the first channel is played starting with the beginning of the concert on (look at the audio meter, on my system it corresponds to the left speaker)?
The channel configuration definitely switches on-the-fly in the stream (look again at the audio meter at the beginning of the sample where two channels are alive and later when only the first one pulses), but it doesn't disturb Avidemux much. The reason of severe problems with my sample was a different one (maybe there was really a gap in data at the point of # of channels switch?).
The beginning & the end are not obviously different
Looks like playing in sync here. when you have the audio settings like in the screenshot. Save the audio, you should get an AC3 audio file, drag and drop that in audacity:
File (4.76 MB total) AC3usedFootage
Will be deleted on 6 September, 2016
Download link https://we.tl/09nDBfKWzL
The video as such is damaged at begin due to dd skip 1.2 GB and saving 127 MB after that point
Don't make your observations with avidemux as player !!!!
You should get this after drag and drop into audacity of above ac3 avidemux saved audio, confirming all audio channels are present.
On my system, when played in Avidemux with the ac3 track active and set as the first track, the audio meter shows two channels (the very first and the very last) pulsing at the beginning. Starting with the beginning of the concert, only the indicator for the first channel is moving. Is it different on your system?
I use AlsaDefault as audio output device and "No downmixing". I have only stereo speakers, no surround.
Preferences: [Audio]
Local playback downmixing [No Downmixing] try Pro Logic or Pro Logic II here
AudioDevice: Pulse AudioS
Pro Logic:
Quote from: Jan Gruuthuse on August 30, 2016, 05:20:53 PM
Looks like playing in sync here.
Are you sure? The video plays sort of at a half speed on my system with your (and my) sample, audio plays at the right speed, no matter which track.
Quotewhen you have the audio settings like in the screenshot.
The screenshot is from Audacity, how is it related? I don't doubt that the audio contains 6 channels, but Avidemux plays just the first one past the layout switch.
QuoteThe video as such is damaged at begin due to dd skip 1.2 GB and saving 127 MB after that point
This should not matter at all. TS streams may start and end at any point. A player should be able to find the first usable key frame and ignore the damaged part prior to that. Avidemux seems to accomplish this just fine.
QuoteDon't make your observations with avidemux as player !!!!
I don't agree. Avidemux is not a
dedicated video player, sure, but the wrong framerate in this case could be avoidable. At least ffplay, which is also not a real dedicated video player (yet), gets it right. Avidemux should be basically usable as a player to decide on cut points and AV offset (and it is in most cases).
Quotereacting audio meters
1 1st moves
2 not reacting
3 3rd moveds
4 not reacting
5 not reacting
6 not reacting
At which position of the stream? Still, it definitely doesn't match my experience at any position. Starting with the jingle at 16.413 only the first one moves.
PS: Yes, downmixing helps, and masks the place where the channel layout switches.
Me bad, was stereo track and sound is really muffled (center track perhaps?)
with prologic or prologicII it should be beter.
You could be having issues with Dual Core and 720p and decoding AC3?
I'm on 4 core intel (core I7), video decoding with GTX 960 vdpau?
try muxing with avidemux into mkv put on USB stick and play that on flatscreen tv, if it plays media or from Blue-ray or DVD player or sat receiver.
If that plays fine on one of those devices, your hitting a bottleneck somewhere on the computer
ProLogicII:
Jingle in prologic see the increased peek.
Try playing with zoom 1:4 (numeric keypad)
AlsaDefault Or PulseAudioS doe not make any difference.
Local playback downmixing with either Stereo, Pro Logic or Pro Logic II
If you look at the audacity screen shot (that is the full length of that audio track) you don't see a switch occurring.
1st & 2nd = left and right.
3rd track = center
4th track = subwoofer
5th track = surround
6th track = surround
The other option is that the PMT mapping is changing
i.e. it starts with audio track PID=400
and later on it is mapped to PID=403
Avidemux can't find PID=400 so no more audio
this pops up while playing ac3UsedFootage with only ac3 track selected:
[AudioStream] Warning skew in dts =-226011,
[AudioStream] Warning skew lastDts=00:00:00,493
[AudioStream] Warning skew newDts=00:00:00,267
[rewind] [AudioBridge] Going to time 00:00:00,493
[goToTime] go to time 0,49 secs
[goToTime] => seg 0, rel time 0,49 secs
[resetAfterSeek] flushing after seek
No accelerated IMDCT transform found
[AudioStream] Warning skew in dts =-225345,
[AudioStream] Warning skew lastDts=00:00:00,493
[AudioStream] Warning skew newDts=00:00:00,267
[AUDMAudioFilter_Bridge] [Bridge] Starting with time 00:00:00,493 , shift 0 ms
[AUDMAudioFilter_Bridge] [Bridge] Ending with time 00:00:00,493, sample 0
[rewind] [AudioBridge] Going to time 00:00:00,493
[goToTime] go to time 0,49 secs
[goToTime] => seg 0, rel time 0,49 secs
[resetAfterSeek] flushing after seek
No accelerated IMDCT transform found
[AudioStream] Warning skew in dts =-225345,
[AudioStream] Warning skew lastDts=00:00:00,493
[AudioStream] Warning skew newDts=00:00:00,267
[rewind] [AudioBridge] Going to time 00:00:00,493
[goToTime] go to time 0,49 secs
[goToTime] => seg 0, rel time 0,49 secs
[resetAfterSeek] flushing after seek
No accelerated IMDCT transform found
[AudioStream] Warning skew in dts =-225345,
[AudioStream] Warning skew lastDts=00:00:00,493
[AudioStream] Warning skew newDts=00:00:00,267
[getPCMPacket] [Composer::getPCMPacket] Track 2,24efa60 : drift 225345, computed :00:00:00,493 [getPCMPacket] got 00:00:00,267
[Composer::getPCMPacket] Track 2:24efa60 : Dropping packet 493 last =267
[getPCMPacket] [Composer::getPCMPacket] Track 2,24efa60 : drift 193345, computed :00:00:00,493 [getPCMPacket] got 00:00:00,299
[Composer::getPCMPacket] Track 2:24efa60 : Dropping packet 493 last =299
[getPCMPacket] [Composer::getPCMPacket] Track 2,24efa60 : drift 161345, computed :00:00:00,493 [getPCMPacket] got 00:00:00,331
[Composer::getPCMPacket] Track 2:24efa60 : Dropping packet 493 last =331
[getPCMPacket] [Composer::getPCMPacket] Track 2,24efa60 : drift 129345, computed :00:00:00,493 [getPCMPacket] got 00:00:00,363
[Composer::getPCMPacket] Track 2:24efa60 : Dropping packet 493 last =363
[getPCMPacket] [Composer::getPCMPacket] Track 2,24efa60 : drift 97345, computed :00:00:00,493 [getPCMPacket] got 00:00:00,395
[Composer::getPCMPacket] Track 2:24efa60 : Dropping packet 493 last =395
[getPCMPacket] [Composer::getPCMPacket] Track 2,24efa60 : drift 65345, computed :00:00:00,493 [getPCMPacket] got 00:00:00,427
[Composer::getPCMPacket] Track 2:24efa60 : Dropping packet 493 last =427
[getPCMPacket] [Composer::getPCMPacket] Track 2,24efa60 : drift -62655, computed :00:00:00,493 [getPCMPacket] got 00:00:00,555
DeviceStopped -> DeviceStopped
[localInit] Pulse, initiliazing channel=2 samplerate=48000
[localInit] [PulseSimple] open ok
DeviceStopped -> DeviceStarted
[stop] [audioDevice]Stopping device... DeviceStarted -> DeviceStop_Requested
[AudioDeviceThreaded] Entering loop
DeviceStop_Requested -> DeviceStop_Granted
[AudioDeviceThreaded] Exiting loop
[PulseAudio] Stopped
DeviceStop_Granted -> DeviceStopped
DeviceStopped -> DeviceStopped
[localInit] Pulse, initiliazing channel=2 samplerate=48000
[localInit] [PulseSimple] open ok
DeviceStopped -> DeviceStarted
[Playback] Latency : 50 ms
[AudioDeviceThreaded] Entering loop
[Playback] Latency is now 0
Thank you, but it is not a performance issue at all. My rather outdated hardware is still capable of playing 1080p h264 videos with Avidemux' Lavcodec decoder without a hitch, even better with VDPAU, though the architectural peculiarities of Avidemux limit the benefits of VDPAU compared with mplayer consuming below 5% CPU when playing 1080p h264 videos thanks to VDPAU decoding.
By the way, remuxing your sample TS file with ffmpeg using
ffmpeg -i AC3UsedFootage.ts -map 0:1 -map 0:6 -c copy AC3UsedFootage-remuxed-with-ffmpeg.mkvdoesn't make C3UsedFootage-remuxed-with-ffmpeg.mkv correctly playable in Avidemux, the video is still much slower than audio.
The questions are:
1) What was arte HD doing wrong in my sample which made Avidemux think the ac3 track didn't continue past channel layout switch?
2) What makes Avidemux choose a wrong video framerate with both sample videos?
QuoteJingle in prologic see the increased peek.
The point where the channel layout switches is actually audible even with downmixing, but the behaviour without downmixing is just... surprising (even if this is a bug, it is not really an issue).
QuoteAlsaDefault Or PulseAudioS doe not make any difference.
The volume slider in Avidemux doesn't work with PulseAudio Simple (this is an API limitation).
Quote from: meanThe other option is that the PMT mapping is changing
i.e. it starts with audio track PID=400
and later on it is mapped to PID=403
Avidemux can't find PID=400 so no more audio
Thank you, actually there is a big discontinuity in video timestamps(?) in the stream at the place where Avidemux drops the ac3 audio track according to ffplay:
76505.02 A-V: 0.058 fd= 104 aq= 48KB vq= 3321KB sq= 0B f=0/02 frames later:
95446.68 A-V:18941.638 fd= 81 aq= 48KB vq= 3263KB sq= 0B f=0/03 frames later back to normal:
76505.61 A-V: 0.503 fd= 81 aq= 48KB vq= 3225KB sq= 0B f=0/0This looks really like a crazy thing arte HD was doing.
Quote from: mean on August 30, 2016, 06:20:45 PM
The other option is that the PMT mapping is changing
i.e. it starts with audio track PID=400
and later on it is mapped to PID=403
Avidemux can't find PID=400 so no more audio
I apologize for my ignorance if I misunderstand the role of PMT, but while I'm unable to identify the mapping exactly at the crucial location in the stream, ffplay shows the very same program (10302) and stream (0x13fc) IDs for the beginning of the sample and a fragment cut with
tail -c 100M testcase-ac3-framerate-issue.ts > fragment.tswhich starts just after the problematic spot.
The info is in the idx2 file
language=fra
Track2.pid=13fc
Track2.codec=8192
Track2.fq=48000
I'll have to look deeper.
It could be a temporary switch to another pid & back
Avidemux tries for a given length to find the pid it wants, after that it fails
It is possible, since seeking after 1mn works well
You can try changing the value in dmxTsPacket.cpp
That's the one :
#define MAX_SKIPPED_PACKET 150*100 // 150*180*100=~ 2.2 MBytes
you can try to put a 20 times larger value
Thank you, increasing MAX_SKIPPED_PACKET from 150*100 to 150*100*20 doesn't help with a dropped ac3 track.
I wonder whether
Audio bf:04037640 Pes:13f8:04032578:0:2590175582 Pes:13f9:04032634:0:2590175582 Pes:13fc:0401fe40:0:2590168975 Pes:13fd:04034e98:0:2590176482
Video at:0401b124:001e Pts:2590274305:2590270705 DF:017341:0:0 PF:002f97:14400:1800 BF:0004c3:7200:3600 BF:0019e4:1800:-1 BF:001cc9:3600:-1 BF:000357:5400:-1 BF:0005ec:9000:10800 BF:000224:10800:12600 BF:0006b3:12600:14400 PF:000e58:28800:16200 BF:0166c8:21600:18000 BF:0002c2:16200:-1 BF:000327:18000:-1 BF:000248:19800:-1 BF:000352:23400:25200 BF:00023b:25200:27000 BF:017f34:27000:28800 PF:001873:43200:30600 BF:000e0f:36000:32400 BF:000308:30600:-1 BF:00029e:32400:-1 BF:00026d:34200:-1 BF:01f2c6:37800:39600 BF:00056c:39600:41400 BF:0002b2:41400:43200
Audio bf:040b77e4 Pes:13f8:040b3d24:0:2590210142 Pes:13f9:040b3de0:0:2590210142 Pes:13fc:0409a708:0:2590203535 Pes:13fd:040b7d08:0:2590211042
Video at:040b3398:001e Pts:2590331905:2590315705 DF:003c02:0:0 BF:000836:-7200:1800 BF:00055d:-12600:-1 BF:019f74:-10800:-1 BF:000274:-9000:-1 BF:000338:-5400:9000 BF:0000d3:-3600:10800 BF:0188d5:-1800:12600 PF:0003a1:14400:14400 BF:0001b3:7200:16200 BF:0000a3:1800:-1 BF:0004b0:3600:-1 BF:000060:5400:-1 BF:0004f2:9000:23400 BF:00004a:10800:25200 BF:000552:12600:27000 PF:0000f4:28800:28800 BF:0007a0:21600:30600 BF:000040:16200:-1 BF:018df0:18000:-1 BF:000040:19800:-1 BF:000551:23400:37800 BF:000042:25200:39600 BF:000602:27000:41400 PF:000aff:41400:43200 BF:014526:36000:45000 BF:000043:30600:-1 BF:00054b:32400:-1 BF:000043:34200:-1 BF:00058a:37800:52200 BF:000087:39600:54000 PF:0171b1:43200:55800
Audio bf:0416af4c Pes:13f8:04154a64:0:2590261982 Pes:13f9:04154b20:0:2590261982 Pes:13fc:041522bc:0:2590261135 Pes:13fd:04157d10:0:2590262882
Video at:0416aba0:001e Pts:2590376905:2590373305 DF:00017c:0:0
Audio bf:0416bb0c Pes:13f8:04154a64:0:2590261982 Pes:13f9:04154b20:0:2590261982 Pes:13fc:041522bc:0:2590261135 Pes:13fd:04157d10:0:2590262882
Video at:0416af4c:001e Pts:2590378705:2590375105 DF:000952:0:0
Audio bf:04173c4c Pes:13f8:04174ea8:0:2590270622 Pes:13f9:04174f64:0:2590270622 Pes:13fc:0417c1f4:0:2590272655 Pes:13fd:04178210:0:2590271522
Video at:0416bb0c:001e Pts:2590380505:2590376905 DF:006f5b:0:0 PF:0098c3:5400:1800 BF:0008f8:1800:3600 BF:0006e4:3600:5400 PF:01147e:9000:7200 BF:001876:7200:9000 PF:00f001:12600:10800 BF:001b0a:10800:12600 PF:0108ac:16200:14400 BF:001f3b:14400:16200 PF:014991:19800:18000 BF:00246b:18000:19800 PF:01b54c:34200:21600 BF:00cc2d:27000:23400 BF:005100:21600:-1 BF:003e4c:23400:-1 BF:001f2e:25200:-1 BF:002784:28800:30600 BF:00283c:30600:32400 BF:001abc:32400:34200 PF:016f7d:45000:36000 BF:009dfc:39600:37800 BF:001cac:36000:-1 BF:001e53:37800:-1 BF:0019be:41400:43200 BF:0017a2:43200:45000
Audio bf:0428cb68 Pes:13f8:0427cf84:0:2590331102 Pes:13f9:0427d040:0:2590331102 Pes:13fc:04279290:0:2590330255 Pes:13fd:04281258:0:2590332002
Video at:0424e9cc:001e Pts:2590438105:2590423705 DF:036618:0:0 BF:008d06:-5400:1800 BF:002370:-10800:-1 BF:00277d:-9000:-1 BF:001c60:-7200:-1 BF:001a8d:-3600:9000 BF:001823:-1800:10800 PF:013312:14400:12600 BF:0094e7:7200:14400 BF:0013db:1800:-1 BF:002238:3600:-1 BF:002170:5400:-1 BF:001ae8:9000:21600 BF:002310:10800:23400 BF:001dae:12600:25200 PF:014296:28800:27000 BF:0099a3:21600:28800 BF:00172c:16200:-1 BF:0023b3:18000:-1 BF:0021e4:19800:-1 BF:001ab0:23400:36000 BF:002207:25200:37800 BF:001c4b:27000:39600 PF:015ba1:43200:41400 BF:009b71:36000:43200 BF:00178b:30600:-1 BF:0023a0:32400:-1 BF:0022b2:34200:-1 BF:001aaa:37800:50400 BF:0022d3:39600:52200 BF:001d5a:41400:54000
starting at line 220 of the corresponding idx2 file describes the problematic spot. Still, Pes:13fc appears at every line prefixed with Audio in the [Data] section.
Meanwhile I've found more problematic streams, all recorded from arte HD over DVB-S2 in recent years, and they all showed an already mentioned timestamp jump (audio, not video) in the ac3 track when frame-stepping in mplayer (mplayer has a better console output as ffplay for this purpose), two examples:
A:76504.6 V:76504.6 A-V: 0.000 ct: -1.074 0/ 0 1% 0% 1.8% 0 0
A:76504.6 V:76504.6 A-V: 0.000 ct: -1.074 0/ 0 1% 0% 1.8% 0 0
A:95446.3 V:76504.7 A-V:18941.617 ct: -1.072 0/ 0 1% 0% 1.9% 0 0
A:95446.3 V:76504.7 A-V:18941.615 ct: -1.070 0/ 0 1% 0% 1.9% 0 0
A:95446.3 V:76504.7 A-V:18941.613 ct: -1.068 0/ 0 1% 0% 1.9% 0 0
A:95446.3 V:76504.7 A-V:18941.609 ct: -1.066 0/ 0 1% 0% 1.8% 0 0
A:95446.4 V:76504.7 A-V:18941.609 ct: -1.064 0/ 0 1% 0% 1.8% 0 0
A:95446.4 V:76504.8 A-V:18941.607 ct: -1.062 0/ 0 1% 0% 1.8% 0 0
A:76505.2 V:76504.8 A-V: 0.424 ct: -1.060 0/ 0 1% 0% 1.9% 0 0
A:76505.2 V:76504.8 A-V: 0.422 ct: -1.058 0/ 0 1% 0% 1.9% 0 0
and
A:13283.2 V:13283.2 A-V: 0.000 ct: -0.960 0/ 0 1% 0% 2.2% 0 0
A:13283.2 V:13283.2 A-V: 0.000 ct: -0.960 0/ 0 1% 0% 2.2% 0 0
A:95446.3 V:13283.3 A-V:82163.008 ct: -0.958 0/ 0 1% 0% 2.3% 0 0
A:95446.3 V:13283.3 A-V:82163.008 ct: -0.956 0/ 0 1% 0% 2.3% 0 0
A:95446.3 V:13283.3 A-V:82163.000 ct: -0.954 0/ 0 1% 0% 2.3% 0 0
A:95446.3 V:13283.3 A-V:82163.000 ct: -0.952 0/ 0 1% 0% 2.3% 0 0
A:95446.3 V:13283.3 A-V:82163.000 ct: -0.950 0/ 0 1% 0% 2.3% 0 0
A:95446.4 V:13283.4 A-V:82163.000 ct: -0.948 0/ 0 1% 0% 2.3% 0 0
A:13283.8 V:13283.4 A-V: 0.422 ct: -0.946 0/ 0 1% 0% 2.3% 0 0
A:13283.8 V:13283.4 A-V: 0.420 ct: -0.944 0/ 0 1% 0% 2.3% 0 0
There are in all cases 6 frames in the ac3 track with wildly wrong audio timestamps. The values of these timestamps are identical across different recordings. Such places in the TS stream derail Avidemux when saving in copy mode to another container like mkv while ffmpeg happens to swallow this irregularity.
Now for the slow playback issue: I experimented with a 3sat HD stream and it seems that Avidemux needs at least 5 minutes of video duration to keep AV sync reliably. Samples shorter than approx. 280 seconds (~360 MiB of stream) start to behave funny.
It starts as 5.1 then switches to stereo at 50s
Thank you. It turns out to be that deleting just about 4 GOPs around the offending spot allows Avidemux to generate a mkv with full uninterrupted ac3 track despite # of channels switch.
Actually both claims in the subject "Wrongly halved framerate, ac3 audio unusable after a channel number switch" of this topic proved to by bloody wrong. The halving of FPS has nothing to do with slow video playback and AV async and channel # switch has probably nothing to do with cut off ac3 track :-[
Adjusting the subject for this post.
The other probblem is that it switches, the audio goes back in time causing an error
That could be fixed i think
Should be ok now
Confirming that the issue of the ac3 track being cut off due to timestamp jump is fixed by [audioCore] try to ignore packets that are out of range Dts wise (https://github.com/mean00/avidemux2/commit/5de3ef9689ed190e9ecf360bcfb231e40d339992). Merci mille fois !
Do you think it could be worth your effort if you look into video playback speed in Avidemux / async with relatively short TS streams as well?
Sorry for the mess I've made out of this topic mixing unrelated issues together.
Could be :
* CPU maxxed out
* Audio clock drifting
Thank you, top shows each core between 30% and 40% idle when playing the testcase (by the way, Xorg causes even higher CPU load as the avidemux3_qt5 process when playing a 720p video in Avidemux), so CPU is probably not an issue. Audio is played at correct pace. The problem emerges only with sufficiently short streams, in my testing below 400 MiB in size and 5 minutes in duration. Avidemux plays the original, uncut version of the very same stream with video in sync when the total length of the stream is higher.
If it resyncs after you seek, the audio clock drifting could be it
The sync is done on video, it is assumed the audio is correct
If the error is small, you'd need to wait a while for it to accumlate
Or it could be a bug
Quote from: mean on August 31, 2016, 06:31:10 PM
If it resyncs after you seek, the audio clock drifting could be it
Yes, it definitely resyncs on seek, then drifts quickly apart when playing, with video running approx. 10% slower than the audio (but it again depends somewhat on the length of the sample, shorter samples resulting in slower video) in the case of the sample provided by Jan in http://avidemux.org/smif/index.php/topic,17079.msg76631.html#msg76631 (http://avidemux.org/smif/index.php/topic,17079.msg76631.html#msg76631).
QuoteOr it could be a bug
I wouldn't doubt it ;)
It's not obviously desync'ed for me
Something strange is going on. Just discovered that...
- If I let Avidemux play the sample offscreen on another virtual desktop, there is no desync when I return back to it, but it develops quickly when Avidemux plays on the current virtual desktop and the video is rendered to the screen.
- If I let Avidemux play in foreground on the current virtual desktop but hide the navigation toolbar, there is no desync too.
The way the position slider gets rendered must induce some bad interactions with gnome-shell, compositing, Xorg etc. This explains also why short samples exhibit the problem while long do not: the jerky slider (http://avidemux.org/smif/index.php/topic,17060.0.html) trembles with higher amplitude if a sample has less frames. In a long sample the updates for the slider happen not so often.
tl;dr:The "slow motion" problem with short samples seems to be a performance issue related to the way the position of the slider in the navigation toolbar is updated and how the slider is rendered.
Could be
I'm using KDE, and i did not spot any issue
Qt & Gnome/unity do not always play nicely together
Sure, but it looks like refactoring of the slider code could bring a substantial benefit for the performance (maybe it would be better to continue in http://avidemux.org/smif/index.php/topic,17060.0.html (http://avidemux.org/smif/index.php/topic,17060.0.html)).
- avidemux uses minimal 2 threads, you can't set it lower in preferences. 2 core cpu without HT hits the bottleneck if the OS is trying to do something.
- moving slider involves big data transfer: 720p video on average 6.2 GB for 1 hour of recording.
performance decreases by older hardware
- Sata I = up to 150MB/s / II = up to 300MB/s / III up to 600MB/s
- Hard disk = Mechanical drive usually top out no faster than 180MB/s at the very fastest
5,400 RPM HDD 75 MB/s
7,200 RPM HDD 100 MB/s
10,000 RPM HDD 140 MB/s- USB 2.0 in practice you'll never get above 40MB/s
- USB 2.0 in practice you'll never get above 40MB/s
USB 2.0 flash drives: 33MB/s reads and 15MB/s writes out of most USB 2.0 flash drives.
- available memory
- ...
used sources:
Difference between SATA I, SATA II and SATA III (http://kb.sandisk.com/app/answers/detail/a_id/8142/~/difference-between-sata-i%2C-sata-ii-and-sata-iii)
Adam Savage's tested (http://www.tested.com/tech/pcs/457172-why-storage-drive-speeds-dont-hit-their-theoretical-limits/)
Quote from: mean on August 31, 2016, 08:49:21 PM
I'm using KDE, and i did not spot any issue
I can't reproduce the issue on Plasma either, despite Xorg load being very high when playing even a very small video in Avidemux :o
With gnome-shell, a bigger size of Avidemux window (making the navigation toolbar longer) makes the issue much worse, while video resolution and size of the video surface almost doesn't matter.
The issue is completely unrelated to disk I/O as short, low resolution videos using computationally cheap codecs like Xvid only a couple of megabytes in size are sufficient to trigger the issue on a moderately powerful desktop PC running GNOME with gnome-shell.
@Jan:
Could you please test if the slow video / progressive desync issue with short videos (from 2 to 4 minutes long) and maximized Avidemux window in foreground is reproducible with Unity?
I'll test later on Xfce.
(Now imagining a mplayer-style warning: "Your system is too slow to render this navigation slider!" ;D)
This turns out to be a QT "gtk" theme issue with the current value for ADM_LARGE_SCALE in Q_qui2.cpp:47. Halving the value is already sufficient to avoid the problem on my system, further reduction provides a security margin. Alternatively, forcing another QT theme e.g. via
export QT_STYLE_OVERRIDE=breeze
or
export QT_STYLE_OVERRIDE=fusion
in the console prior to running avidemux3_qt5 helps as well. This said, it could be possible to reproduce the issue on KDE when launching Avidemux with
QT_STYLE_OVERRIDE=gtk avidemux3_qt5
Oddly enough, setting refreshCapEnabled to true and refreshCapValue to any value in the allowed range seems to have no effect at all.
Quote from: eumagga0x2a on September 01, 2016, 06:22:26 PM
@Jan:
Could you please test if the slow video / progressive desync issue with short videos (from 2 to 4 minutes long) and maximized Avidemux window in foreground is reproducible with Unity?
I'll test later on Xfce.
(Now imagining a mplayer-style warning: "Your system is too slow to render this navigation slider!" ;D)
You could be on to something. I never noticed the issue: I never use avidemux as player. Just editing.
To understand clearly:
In avidemux playing any video (screensize / codec) after playing 5 minutes audio is delayed: AC3 only?
Display:
- VDPAU
- X11
- OpenGL
- Libva
with avidemux using full Full screen? 4K display 3840 x 2160 here.
Last minute countdown counter becomes redish
all tracks should at least play 5 minutes
1st track AC3 5.1
2nd track AC3 stereo
3rd track MP3 stereo
4th track MP2 stereo
Files (85.5 MB total) Avidemux5MinuteSyncTest.mkv (https://www.wetransfer.com/downloads/c06854c839bee634d39061239e9654a520160902112113/7104a8d8f4d8ce73deed487aed9baf7120160902112113/f8c92a)
Will be deleted on 9 September, 2016
Thank you very much for your testing.
Quote from: Jan Gruuthuse on September 02, 2016, 10:12:24 AM
You could be on to something.
Not really as the nature of the issue has been identified already. The problem is related to the Qt theme in use quite like http://avidemux.org/smif/index.php/topic,16742.msg75823.html (http://avidemux.org/smif/index.php/topic,16742.msg75823.html). The workaround (or a solution, depends on your point of view) is to reduce the value for https://github.com/mean00/avidemux2/blob/master/avidemux/qt4/ADM_userInterfaces/ADM_gui/Q_gui2.cpp#L47 (https://github.com/mean00/avidemux2/blob/master/avidemux/qt4/ADM_userInterfaces/ADM_gui/Q_gui2.cpp#L47). It was already lowered once to avoid Avidemux being rendered completely unusable by the "adwaita-qt" Qt theme.
QuoteI never noticed the issue: I never use avidemux as player. Just editing.
Me too (simply looking at the system load caused by Avidemux is enough to abstain from using it purely as a video player), but footages of classical music performances are often poorly synchronised and Avidemux usually provides an easy way to counteract this pre-existing A-V offset. I use Avidemux as player to identify the proper value for the audio delay. For this purpose Avidemux may not introduce its own A-V desync, obviously ;)
QuoteTo understand clearly:
In avidemux playing any video (screensize / codec)
Yes...
Quoteafter playing 5 minutes
No, it starts to desync immediately, but the effect must accumulate a bit to become clear (usually 10 seconds are enough depending on the footage). The video must be short to make steps the position slider has to accomplish reflecting the playback status bigger.
Quoteaudio is delayed
No, video gets delayed.
QuoteAC3 only?
No, the audio codec similar to the video codec doesn't matter at all.
QuoteDisplay:
- VDPAU
- X11
- OpenGL
- Libva
Doesn't matter, but the video driver (nvidia|nouveau|intel|radeon|amdgpu) may play a role (though unlikely).
Quotewith avidemux using full Full screen? 4K display 3840 x 2160 here.
Bigger Avidemux window makes a longer navigation toolbar makes bigger steps for the slider makes it easier to reproduce the issue.
tested with commit f4272d2
- X11
- XVideo
- VDPAU
- OpenGL
no video had any noticeable delay when testing with AC3 5.1 or AC3 Stereo during the 5 minute playback on fullscreen with ubuntu 14.04.5 lts amd64 on somewhat aged system:
Hardware:
QuoteProcessor: Intel Core i7-3770K @ 3.90GHz (8 Cores), Motherboard: ASRock Z77 Extreme3, Chipset: Intel Xeon E3-1200 v2/3rd, Memory: 32768MB, Disk: 2 x 1000GB Western Digital WD1002FAEX-0 + 2 x 4001GB Western Digital WD4003FZEX-0, Graphics: ASUS NVIDIA GeForce GTX 960 2048MB (1417/3600MHz), Audio: Intel 7 /C210, Network: Realtek RTL8111/8168/8411
Software:
QuoteOS: Ubuntu 14.04, Kernel: 3.19.0-68-generic (x86_64), Desktop: Unity 7.2.6, Display Server: X Server 1.15.1, Display Driver: NVIDIA 352.99, OpenGL: 4.3.0, Compiler: GCC 4.8.4 + CUDA 7.5, File-System: ext4, Screen Resolution: 4920x2160
Quote from: Jan Gruuthuse on September 02, 2016, 02:58:35 PMno video had any noticeable delay when testing with AC3 5.1 or AC3 Stereo during the 5 minute playback on fullscreen with ubuntu 14.04.5
Was it a Qt4 build then? I referred only to Qt5 builds in this topic and didn't test with Qt4 builds at all, so I don't know whether you might expect to see the issue there.
On the other hand, 5 minutes duration is too long to make the issue appear even on my system which is 25% as powerful as yours at best. You could try if a shorter video (no need to generate a new sample, just delete temporarily a section of the video in Avidemux) of max. 2 minutes duration would allow to reproduce the problem, but I guess your hardware is just too ridiculously fast :)
(fixed some grammar)
Quote from: eumagga0x2a on September 02, 2016, 03:39:37 PM
Was it a Qt4 build then? I referred only to Qt5 builds in this topic and didn't test with Qt4 builds at all, so I don't know whether you might expect to see the issue there.
1st time QT5 is mentioned in this thread ;D
Will do some test on QT5 tomorrow ...
Quote from: Jan Gruuthuse on September 02, 2016, 05:14:39 PM
1st time QT5 is mentioned in this thread ;D
Why should it? Qt5 is the default. It is Qt4 which should be specifically outlined. I still expect both behave the same in this case when using the same Qt "gtk" style.
Anyway, the workaround for those with modest hardware is cheap and straightforward and I am unable to contribute to a more efficient slider implementation.
On our YouTube channel Avidemux Demo (https://www.youtube.com/channel/UC7ycUgCIuOlChtpiTFfLTmw/videos?flow=grid&view=0&sort=dd) you can find Audio Sync Delay Test 10 seconds (http://audiosyncdelaytest10seconds) amongst some more durations 20,30 seconds, 1,2,3,4 and 5 minutes.
Thanks, are these countdown videos with AV perfectly in sync really screencasts? It would have been helpful to see at least parts of Avidemux GUI too, especially the navigation toolbar.
(The issue affects only playback, not saving.)
Done test with sync delay video. And could not notice a delay on ubuntu 16.04.1 amd64 unity desktop with QT5
Quote from: eumagga0x2a on September 03, 2016, 09:26:07 PM
Thanks, are these countdown videos with AV perfectly in sync really screencasts? It would have been helpful to see at least parts of Avidemux GUI too, especially the navigation toolbar.
(The issue affects only playback, not saving.)
No the videos are not a desktop recording of avidemux playing the test video. If I under stood your question correctly.
I will try to make such a desktop recording, but my system is most likely not powerful enough doing so at 25 fps in full 4K screen. I did run in recording issues before.
Quote from: Jan Gruuthuse on September 04, 2016, 05:32:04 AM
Done test with sync delay video. And could not notice a delay on ubuntu 16.04.1 amd64 unity desktop with QT5
Thank you, then your system is fast enough to cope with the high graphical load caused by the navigation slider with the QT5 "gtk" theme.
Quote from: Jan Gruuthuse
Quote from: eumagga0x2a on September 03, 2016, 09:26:07 PM
Thanks, are these countdown videos with AV perfectly in sync really screencasts? It would have been helpful to see at least parts of Avidemux GUI too, especially the navigation toolbar.
(The issue affects only playback, not saving.)
No the videos are not a desktop recording of avidemux playing the test video. If I under stood your question correctly.
I see that you expected a progressive desync while in playback mode (if it happens) to be present also in the results of Avidemux remuxing or reencoding the source video. No, the issue affects only the playback, never saving. Comparing saved videos was useless. In case you could reproduce the issue despite having such a beast of a PC, just filming the screen with a camera while Avidemux plays a sample would deliver a proof, if you would want to deliver a perfect proof (which I don't actually need).
Quote
I will try to make such a desktop recording, but my system is most likely not powerful enough doing so at 25 fps in full 4K screen. I did run in recording issues before.
I really think it was sufficient that you looked at the screen and reported what you saw, if I managed to explain you the issue clear enough, of course.
Anyway the desktop recordings went OK (previous recording issue seems solved)
Test 4K: X11, XVideo, OpenGL, VDPAU, VDPAU Hardware-accelerated, LibVA and LibVA Hardware-accelerated.
Avidemux v2.6.13 (160904_ 09b745b6d9b) File: Audio Sync Delay Test 30 seconds
On our YouTube channel: Avidemux Demo (https://www.youtube.com/channel/UC7ycUgCIuOlChtpiTFfLTmw) the videos of the tests:
X11 (https://www.youtube.com/watch?v=dPmYGPRze6c)
XVideo (https://www.youtube.com/watch?v=KgWgwx5ow2k)
OpenGL (https://www.youtube.com/watch?v=nWgUJKvt1KU)
VDPAU (https://www.youtube.com/watch?v=_soJ6R8QukM)
VDPAU Hardware-accelerated (https://www.youtube.com/watch?v=QSk-wBPMAzw)
LibVA (https://www.youtube.com/watch?v=S7cE4-71QIE)
LibVA Hardware-accelerated (https://www.youtube.com/watch?v=go6JKmMzHls)
Hardware:
Processor: Intel Core i7-3770K @ 3.90GHz (8 Cores), Motherboard: ASRock Z77 Extreme3, Chipset: Intel Xeon E3-1200 v2/3rd, Memory: 32768MB, Disk: 2 x 1000GB Western Digital WD1002FAEX-0 + 2 x 4001GB Western Digital WD4003FZEX-0, Graphics: ASUS NVIDIA GeForce GTX 960 2048MB (1012/3600MHz), Audio: Realtek ALC892, Network: Realtek RTL8111/8168/8411
Software:
OS: Ubuntu 16.04, Kernel: 4.4.0-36-generic (x86_64), Desktop: Unity 7.4.0, Display Server: X Server 1.18.3, Display Driver: NVIDIA 361.42, Compiler: GCC 5.4.0 20160609 + CUDA 7.5, File-System: ext4, Screen Resolution: 4920x2160
ps.:
QuoteComparing saved videos was useless
those video files are for testing purpose, the test is done in videos in this post.
It is not the "gtk" Qt theme in the recording (it is probably the "fusion" one), the issue doesn't affect fusion and breeze (http://avidemux.org/smif/index.php/topic,17079.msg76704.html#msg76704). You should see a different appearance of Qt widgets if you launch Avidemux with
export QT_STYLE_OVERRIDE=gtk
avidemux3_qt5
Again, video output drivers and decoders don't matter alltogether, you burden yourself with a lot of work which is unrelated to the topic.
I'm really sorry for not having tested with one of your AV sync test YouTube videos earlier, but I can't reproduce the issue already with the very first one I tried: https://www.youtube.com/watch?v=8aGeizQcaoA (https://www.youtube.com/watch?v=8aGeizQcaoA). The most probable reason is 25 fps in the YouTube sample vs. 50 fps in the arte HD one.
Quote from: eumagga0x2a on September 04, 2016, 11:38:08 AMThe most probable reason is 25 fps in the YouTube sample vs. 50 fps in the arte HD one.
Yes, it is: If I reencode the mentioned YouTube sample and insert the "Resample FPS" filter with 50 fps as the target value, I can reproduce the problem.
Audio Sync Delay Test 30 seconds 720p 50 FPS YouTube Audio Sync Delay Test 30 seconds 50 FPS (https://www.youtube.com/watch?v=uoqjyCRImec)
50 individual frames, not 25 fps re-encoded to 50 fps
Files (920 KB total), Will be deleted on 11 September, 2016
Mkv Download: 720p50fps30seconds.mkv (https://we.tl/MjIzcnpn3M)
Thank you for one more perfect sample. Are you able to reproduce the issue with this video and "gtk" Qt theme on your system?
Quote from: Jan Gruuthuse on September 04, 2016, 06:21:47 PM
50 individual frames, not 25 fps re-encoded to 50 fps
Actually it doesn't matter much, the tiny sample from YouTube reencoded at 50 fps shows similar AV desync between 10% and 20% on my system. It means, FPS is a very important part of the game here.
Tested and recorded (25 fps):
- Tested: export QT_STYLE_OVERRIDE=gtk avidemux3_qt5 4K 50 FPS (https://www.youtube.com/watch?v=Rb1HBCrVEFc)
- Tested: NO export QT_STYLE_OVERRIDE 4K 50 FPS (https://www.youtube.com/watch?v=CiTTdkdnAyY)
could not notice different behaviour.
Hit the hardware ceiling: not able to record the test @ 50 FPS
so bandwidth could be an issue doing video stuff?
Confirming that there is no desync with "gtk" Qt theme on your system when playing the 50 fps sample in Avidemux. It doesn't matter that you can't record it at 50 fps, generally it was enough what you see with your own eyes. The only important clue from a screencast was to give a hint about the Qt theme in use. Thank you very much.
Offtopic: Your screencasts show how horribly the current solution for the size of the time display fails on HiDPI screens :(
Quote from: eumagga0x2a on September 05, 2016, 07:00:26 AM
Offtopic: Your screencasts show how horribly the current solution for the size of the time display fails on HiDPI screens :(
time displays in avidemux GUI? this what you referring to?
I mean the small text field showing the current playback position in hh:mm:ss.ms. I submitted a patch to accomodate its contents for the "gtk" Qt theme and usual font sizes (https://github.com/mean00/avidemux2/commit/f520bfce55342e0f2e11b053ee953aa85355a4fb (https://github.com/mean00/avidemux2/commit/f520bfce55342e0f2e11b053ee953aa85355a4fb) and https://github.com/mean00/avidemux2/commit/80e4934a9dfafbd5c3411bd34d901dcfcad045a8 (https://github.com/mean00/avidemux2/commit/80e4934a9dfafbd5c3411bd34d901dcfcad045a8)), but it doesn't work nicely with other Qt themes and fails even more on HiDPI according to your screencast. Ideally, the field should be wide enough to allow all digits to fit in with a comfortable padding, but this can't work with fixed sizes specified in pixels.
perhaps a separate floating window with control and timers? That sizes upto (dynamic) to the current screen it floats on?
It looks like recent commits including a partial fix for http://avidemux.org/smif/index.php/topic,17060.0.html (http://avidemux.org/smif/index.php/topic,17060.0.html) have majorly increased the desync effect...
Quote from: Jan Gruuthuse on September 05, 2016, 07:34:13 AM
perhaps a separate floating window with control and timers? That sizes upto (dynamic) to the current screen it floats on?
I guess, we shouldn't replace one evil with another ;)