|
|
| Pamel |
| Posted: Mar 23 2003, 04:54 AM |
 |
|
matroska team member
Group: Moderators
Posts: 151
Member No.: 1353
Joined: 15-December 02
|
It think it would be a lot easier to change one of the AVISynth filters to detect a spot where a frame should probably be, and just output a duplicate decoded frame. But yes, that should work, and would be pretty handy.
--------------------
Please take anything I say with many many grains of salt. I can't tell the difference between my AVI and a hole in the ground. |
|
| fccHandler |
| Posted: Mar 23 2003, 06:41 AM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
| QUOTE (Pamel @ Mar 23 2003, 12:54 AM) | | It think it would be a lot easier to change one of the AVISynth filters ... |
Maybe so, but I don't know much about coding Avisynth filters. However, I know quite a lot about VirtualDub's MPEG parser, so for me, adding code to store the PTS stamps in VirtualDub would be less painful.
Anyway, I don't use Avisynth for transcoding MPEG-2 (obviously). 
The only catch is that PTS stamps are not required on every PES packet. TMPGEnc and ATI seem to write them on almost every packet, but I see a lot of DVD VOBs only have PTS on packets containing an I-frame. Still, I suppose the missing PTS stamps could be interpolated from the existing ones...
--------------------
May the FOURCC be with you... |
|
| zib92130 |
 Posted: Mar 23 2003, 08:58 AM |
|
|
Unregistered
|
@Pamel
I was parsing the forum since half a week to find an explanation/solution for my sync prob while converting MPEG (captured by ATI hard/software) to avi. All you have said answered my questions  :
- why captured MPEG is read correctly 
- why vdub doesn't show the same frame rate 'for duration match' for 2 different captured files 
- why the converting avi is 'suddenly' out of sync in the middle of the movie 
So now, due to your explanations, my quest is not 'WHY' anymore, but 'HOW' to overcome this...
Let's go and search and make some tests... 
|
|
| jktla |
| Posted: Mar 27 2003, 05:24 AM |
|
|
Unregistered
|
My sync problem solved when I started to use standard MP3 audio decoder codec when watching video. Now I can record at MPEG2 video and convert it Divx with MP3 sound without any sync proglems, and I don't have to change fps. |
|
| phaeron |
| Posted: Apr 1 2003, 09:14 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Nice try, but I call BS on Pamel's explanation.
First, the argument that the AVI will desync because a section drops to 15 fps is complete bull. The whole purpose of zero-byte drop frames in an AVI video stream is to pad the video frames out to maintain sync and as indicators that has happened. So if the encoder is forced to drop to 15 fps, a drop frame is inserted between each encoded frame and sync is maintained. The decoder can trivially detect that this has been done and can even interpolate between the missing frames if desired. The code to calculate when drop frames are required for a stream that periodically drops below target rate is trivial. If you have a capture program that knows it is receiving a section of frames with twice the period that it is supposed to and writes them back-to-back in the video stream, ditch it and get one that actually works.
Now, as for MPEG....
2.5.1.4 of 11172-4 (MPEG-1 compliance requirements) requires that within any section of audio or video that has no discontinuities, the nominal frame rate must not vary from the average PTS delta over that set of samples by more than 100 parts per million. This means a section with no discontinuities must have precise PTS timestamps and can't have large amounts of jitter in the timing. So what are discontinuities? Well, according to 2.4.5.4 in 11172-1, a discontinuity exists whenever a frame's PTS is larger than the upper bound for that frame given required clock accuracy. That means:
1) PTSs cannot be anachronistic (go backward).
2) PTSs cannot encode frames at a higher rate than the specified picture rate, since that does not quality as a discontinuity and this would violate the precision requirement.
So the local frame rate over any portion of the stream must have a framerate <= that specified. Well, guess what -- AVI drop frames allow you to compensate for such disturbances in the video stream with at most 1/2 frame error. At 30 fps, that's 17ms. Triple buffering in an FPS game will give you more delay than that. Never mind the fact that compliant decoders can't really be expected to continuously play through a discontinuity.
Let's further read D.6.7 in ISO/IEC 11172-2 (MPEG-1 Video), where it says:
| QUOTE |
This part of ISO/IEC 11172 does not allow pictures to be dropped at the encoder. This differs from the case of CCITT Recommendation H.261 where temporal sub-sampling may be done by omitting coded pictures from the sequence. This part of ISO/IEC 11172 requires that all source pictures be encoded and that coded pictures must be inserted into the bitstream nominally at the rate defined by picture_rate field in the sequence header.
|
It goes on to describe how an effective lower frame rate can be achieved by encoding P- and B-frames with all predictions and no DCT data. This is completely transparent to any decoder, including VirtualDub's, as it is indistinguishable from any other regular frame.
So please stop spreading this crap. MPEG does not support VFR, and AVI does not have the sync problem you describe.
|
|
| fccHandler |
| Posted: Apr 1 2003, 05:18 PM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
Isn't it still possible that these captured MPEGs contain drifts in the PTS which are in violation of 11172-4?
How would you explain the frequent reports that a captured MPEG is synchronized in WMP, but out of sync in VirtualDub? If we throw out Pamel's explanation, we're back to square one.
I call upon anyone reading this thread to please provide us with a link to an MPEG which exhibits the behavior described in my previous paragraph. (So far I haven't been able to make one myself, using my own ATI hardware and software.)
--------------------
May the FOURCC be with you... |
|
| Pamel |
| Posted: Apr 1 2003, 09:32 PM |
|
|
matroska team member
Group: Moderators
Posts: 151
Member No.: 1353
Joined: 15-December 02
|
Wow, that would be 2 strikes against me from Avery within the period of a week. Excuse me while I go out to purchase a new ego, the prevoius one having been burnt as an effigy of misinformation. I think it can be safely said to take anything I have said with a few grains of salt, C4, and a few blasting caps. 
I don't remember where I picked up my (mis)information, but I had always assumed it was correct. The only time that I have not had synch issues when making a long capture with dropped frames is when using ATI's native MPEG-2 vcr format. Of course, I had never actually tried to capture to MPEG-1, so I don't know if it is different. And the synch issues seemed related to dropped frames, as synch would be on in the beginning, but the further you got in the stream, the synch would just get a little further off every once in awhile. Changing the framerate would align it a little better, but it would still be off by varying amounts throughout the video.
Of course, maybe I was an idiot there and selected the wrong settings in the different pieces of software I used?
Anyway, comparing my fragmented memory with Avery's knowledge of video would be a fool's game. I will change my previous post to reflect my new found knowledge.
--------------------
Please take anything I say with many many grains of salt. I can't tell the difference between my AVI and a hole in the ground. |
|
| Pamel |
| Posted: Apr 1 2003, 10:58 PM |
|
|
matroska team member
Group: Moderators
Posts: 151
Member No.: 1353
Joined: 15-December 02
|
@fccHandler: Someone has offered an out of synch file for testing with here. I can offer nothing because since I moved, my pc is no longer hooked to any video source.
--------------------
Please take anything I say with many many grains of salt. I can't tell the difference between my AVI and a hole in the ground. |
|
| phaeron |
| Posted: Apr 2 2003, 03:39 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
fccHandler: It could be an out-of-spec file, but here are other things that I can think of off the top of my head that could cause the desync:
1) Audio and video streams not starting at the same time. This can be solved by padding the late stream.
2) Error building up over long periods of time. I have heard stories of people recording MPEGs which, after, decompression, have >2^31 audio samples! Can be resolved by tweaking the video frame rate.
3) Actual discontinuity in the streams. Yuck. Cut off the streams at the discontinuity and then apply (1) to the next segment.
4) Audio or video parser screws up and misses frames. Hard to detect by reports, unfortunately.
It's unfortunately hard to diagnose this problem when all people report is that their file is out of sync, without saying how long it is or if the sync changes over time. I too have not been able to repro the problem with my ATI card and software. ATI also has a funny sound resampling DirectShow filter in their capture software that adds an additional variable into the equation.
The MPEG parser that ships with DirectShow copes with an awful lot of garbage in a file, including raw joins and incorrect GOP timestamps. I get the impression that it mainly syncs through the systems stream and then fine-tunes with the PTS. Works remarkably well for its age, really (dates back to Win95 OSR2!), and certainly better than the crappy DVD player software I got with my laptop, that's for sure.
The main problems with including PTS support:
1) PTSes are a pain to decode because the PTS is tied to the pack that contains the first byte of the frame marker. Consider four packs, each of which hold one byte of the marker -- the PTS is three packs back by the time you have decoded the marker. This is even more annoying when you consider that markers can be preceeded by runs of 00 and you don't know which 00 snags a timestamp until you hit the third marker byte.
2) PTSes are incorrect when a raw join occurs. Enough said.
Most MPEG files are nice and clean and have a video frame per pack, with a PTS+DTS on every I-frame. It's the once that are sliced up (VCD) that are scary.
|
|
| fccHandler |
| Posted: Apr 2 2003, 04:11 AM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
| QUOTE (phaeron @ Apr 1 2003, 11:39 PM) | | Consider four packs, each of which hold one byte of the marker -- the PTS is three packs back by the time you have decoded the marker. |
Hehe. That's far-fetched, but I see your point. Anyway, if you don't think that PTS support will help then I'll strike it from my todo list for now. I'm still waiting to see if someone will post a link to that mythical out-of-sync out-of-spec MPEG they captured...
--------------------
May the FOURCC be with you... |
|
| LeQuack |
| Posted: May 21 2003, 11:06 PM |
|
|
Unregistered
|
Any solution to this yet ? I have a MPEG1 video/audio that I want to encode to xvid/mp3 but the problem is progressive asynchronisation (fine at start, up to 2sec delays at end). If i do "change so audio and video durations match" frame change in Vdub the video is synched in parts, but still not synched elsewhere.
Someone said thet reencoding with TMPEGEnc fixes this, thou not for me. Even if I do just do a demux/mux with TMPEGEnc it loses sync. |
|
| LeQuack |
| Posted: May 22 2003, 03:34 PM |
|
|
Unregistered
|
Okay so I now encoded with TMPEGEnc directly to AVI using xvid/mp3 and the audio/video are perfectly synched. Strange, I couldn't do this with Vdub or VdubMod, nor with nandub, flask... |
|
| sternengaenger |
| Posted: May 30 2003, 05:34 AM |
|
|
Unregistered
|
The problem of the desync video/audio seems to grow.
I heare many people talk about this problem using Vdub.
It seems that playing with WMP or encoding with tmpg or flask
the problem does not exist.
Just a short review.
problem on: mpeg1 29.97fps
vdub suggests a conversion to (about) 30.02 fps to match audio/video.
This suggests a shorter audio-track.
So the suggested problem of dropped frames when capturing the video cannot be the problem, or else the video would be shorter than the audio (and this is not the case)
@phaeron
Do you regard the whole discussion as BS or are you seriously giving it some thoughts?
Thanks for your work. |
|
| phaeron |
| Posted: May 30 2003, 06:17 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
@&*#(&($#
Your question is not as important as you think it is.
If you send me an email, AND send me a private message, AND post in the forum, AND all three messages are exactly the same, you are going to PISS ME OFF. Ask your question ONCE.
Now, to answer your question:
yes
|
|
| fccHandler |
| Posted: May 30 2003, 07:34 AM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
 I'm gonna repeat what I said 2 months ago:
I call upon anyone reading this thread to please provide us with a link to an MPEG which exhibits the behavior I described before. Namely, that it's played in sync by WMP but out of sync in VirtualDub.
(Until I see this firsthand, I refuse to believe it exists.)
--------------------
May the FOURCC be with you... |
|
