Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
29th May 2004, 03:00
|
#81 | Link |
|
Guest
Join Date: Jan 2002
Posts: 21,901
|
@Zep
I don't want to have a debate with you, but the stream does not have a good audio-video event for me to assess the sync. I don't know why you did not respond to this point. Here it is again in case you care to respond: "There is no mouth movement with the uh, so I cannot assess the correct sync. Now if you have the crack of a ball hitting a bat, that is ideal. But there are many frames where the uh could have started." Last edited by Guest; 29th May 2004 at 03:03. |
|
|
|
29th May 2004, 04:53
|
#82 | Link |
|
Registered User
Join Date: May 2004
Posts: 26
|
audio sync
Hi neuron2:
Not to throw more full on the fire but I don't understand why Jackei put the audio delay in the file name in the first place rather than extract the audio as it should match with video. Obviously the players can sync the audio, so the time stamps must be available to be used. Maybe this would require a second pass of file to extract audio to match with video or some other reason you could enlighten us with. Just my $.02 Thank you dtv_user |
|
|
|
|
29th May 2004, 05:37
|
#83 | Link |
|
Guest
Join Date: Jan 2002
Posts: 21,901
|
@dtv_user
I was just wondering the same thing. When we demux to ES, we lose the timestamps, so if we wish to align things, we would need to delete video frames at the beginning if the audio is late, or add video frames if the audio is early. (Alternatively, we could add/delete audio frames.) But it is not easy to insert/delete frames in an MPEG encoded bitstream. |
|
|
|
|
29th May 2004, 10:52
|
#84 | Link |
|
Registered User
Join Date: May 2004
Posts: 26
|
audio sync
Hi neuron2;
Don I have been capturing ATSC clips with differerent resolutions and from different TV stations, they are all different. I've been capturing a daily half hour show from WB (Warner Brothers) and the resolution is 1920 X 1080 . I downsize this to 720 X 480 and author to DVD with AC3 audio to archive. I have a ACCESSDTV computer PCI card and also start my capture 5 minutes early and end 5 minutes late, to get a clean start point. The time stamps are weird numbers like -5 hours which is probably keyed off some master clock the station uses. The delay in DVD2Avi (Nic's) and your versions are negative numbers like -481 and such. I have to actually use a positive offset like 1281 to sync audio. I don't have any way to upload clips to you as my connection is only 31200 on my best days. I've messed with audio sync quite a bit and one of the problems with saving AC3 audio is the delay number is misleading. AC3 audio for my use needs to be cut on a even frame with 0B 77 header at the start of frame. People talk about cutting audio to ths ms but most programs I have tried round the AC3 cut to a audio frame start. I have been loading my audio and video into Mpeg2Schnitt and changing the audio offset to sync,set my starting and ending points, cutting commercials and then saving cut points. Clips can be played in Mpeg2Schnitt to adjust the audio before cutting. I have made a table of ms verses frame start points so I can control the cut points on AC3 frame header start code (0B 77)and not letting the program round off my offsets.I work in AC3 frame offsets rather then ms. The request I have from you is to maybe have a way to show video and audio time stamps in the status box when setting starting cut point with slider in DGindex. If you could have a way to test for alignment of audio frame start header (0B 77) and I frame maybe this could allow for better audio sync. Sorry for the long post. dtv_user |
|
|
|
|
29th May 2004, 16:27
|
#88 | Link |
|
Guest
Join Date: Jan 2002
Posts: 21,901
|
Version 1.0.5 point release
I've released Version 1.0.5 as follows:
* Fixed a small bug in random access. If your stream has leading B frames in display order (the infamous GOP warning popup), and you navigate to one of those frames followed by another jump less than 8 frames forward, you'll get the wrong frame. * The transport parser was not properly parsing video with stream IDs of 0xe8-0xef. The PTS was not being captured although the video ES was delivered, resulting in no audio delay being reported. * The capability was added to demux audio from audio-only transport streams. To do it, set your video PID to 0. * A document containing notes on transport stream decoding was added. http://neuron2.net/fixd2v/dgmpgdec105.zip |
|
|
|
|
29th May 2004, 18:17
|
#89 | Link |
|
Registered User
Join Date: May 2004
Posts: 26
|
audio sync
Hi neuron2;
Glad to see your working on audio Don. I've demuxed the WB(Warner Brother) streams I mentioned earlier with quite a few different demuxers with varing results. I've used bbdmux, xport, projectx, xmuxer, others and DGIndex. Bbmux returns the most number of frames and with the clip I am using DGIdex was 49 AC3 frames later from the start of audio. Projectx gave the best audio sync with these frames using Mpeg2Schmitt to test play after resizing video to 720 x 480. Mpeg2Schmitt won't play the 1920 x 1080 with in sync on my 2.6 P4 PC. Bbmux returned too many audio frames from the clip and was 17 audio frames out of sync. It's suprising how different demuxers return different number of frame from the start of clip. Bbdmux 1.9 doesn't start on a valid AC3 start header (0B 77) when demuxing a transport stream, all the others seem to start with a proper header. Xmuxer will try to cut the audio to sync with video when it demuxes and works good on my PBS 704 X 480 transport streams. Keep searching, The truth is out there somewhere. Thanks again dtv_user |
|
|
|
|
29th May 2004, 19:15
|
#90 | Link |
|
Guest
Join Date: Jan 2002
Posts: 21,901
|
Version 1.0.6
Point release to add fix that allows TMPGE 3 to open D2V files directly. Also changes the icon for DGIndex.
http://neuron2.net/fixd2v/dgmpgdec106.zip |
|
|
|
|
29th May 2004, 20:36
|
#94 | Link | ||
|
Registered User
Join Date: Jul 2002
Posts: 587
|
Quote:
and you didn't read it. First i said and I qoute "ok I will have to make a clip now and test it in VDub to see how far off. I sent that one because I already did the work and knew it was 700ms off." then in my NEXT post i said and I quote "I already Uled a new clip before you even posted so no need to get into that." didn't you read that? i said "no need to get into that" because there isn't and i do not want to debate this and made a new clip for you. That second clip has been on your server for a LONG time. You really have me scratching my head on all this because I did as you asked and made a clip like you said you wanted and ULed it over 24 hours ago.  Quote:
what are you talking about? the second clip i uploaded has lots of talking just like you asked for. it on you server callled about700ms.earlyaudio.tp it is a JUDGE talking and I chose the clip of him saying "FAULT" since the hard F sound on that word is easy to sync too lips wise. REAL EASY. so what is wrong with that clip? Have you looked at it yet? Is that one ok? Last edited by Zep; 29th May 2004 at 21:11. |
||
|
|
|
|
29th May 2004, 23:56
|
#96 | Link |
|
Guest
Join Date: Jan 2002
Posts: 21,901
|
@Zep
I sampled your stream at various points and looked at the PTS values for adjacent audio and video packets carrying PTS. They consistently showed an adjustment of -376, which is what DGIndex reported. But actually encoding in either Vdub or TMPGE required ~+700 as you reported, so something is fishy. It's possible that the capture application is offsetting the PTS of the video to allow for audio buffering in their player application. Buffering is required to make sync adjustments during playback. You say VLC plays it OK too. I'll look at VLC. Is the source code available? Last edited by Guest; 30th May 2004 at 00:01. |
|
|
|
|
30th May 2004, 02:32
|
#98 | Link | |
|
Guest
Join Date: Jan 2002
Posts: 21,901
|
Quote:
|
|
|
|
|
|
30th May 2004, 03:02
|
#99 | Link | ||
|
Registered User
Join Date: Jul 2002
Posts: 587
|
Quote:
is the -376 (in this example) being applied to wav decode and down mix? (just curious since no delay is in file name when i save a wav) Quote:
and why I tested it with VLC to make sure the app that came with my card didn't do something strange. ALL play it back perfectly. I also thought it would not be a true .ts file if they messed with the standards and i could not believe they would mess around like that and that was the second reason i tested in other .ts players and VLC etc... BTW - it is not VDub. When I drop the avs on media classic or WMP or bsplayer I get the problem too. So it does appear to be in DGindex ---> avisynth chain yes the VLC and ffmpeg source is available. it is an open project based on ffmpeg. VLC is really a GUI wrapper project around the ffmpeg core. http://www.videolan.org/vlc/download-sources.html http://sourceforge.net/projects/ffmpeg/ IMHO VLC and mPlayer are the best 2 players for NOT needing any codecs installed because both use lib52/ffmpeg cores to encode/decode (sorta like ffdshow i guess) This has been the biggest problem i see everyone posting about in HDTV forums. You figure this one out and many .ts cappers are gonna be very happy 
Last edited by Zep; 30th May 2004 at 03:04. |
||
|
|
|
 |
|
|
Linear Mode
