Source filters to use avs for playback of telecined streams?

[asc28]

Any DirectShow filters that can playback telecined .vc1, .m2v, .h264 streams correctly without muxing them? Reason I don't want to simply mux into Matroska: applying audio delays is destructive, and I want to preserve the integrity of my files.

Previously, I used an Avisynth script with an indexing source filter, like MPEG2Source or AVCSource. Then I applied IVTC as needed and used AudioDub with the appropriate delay to play the avs in MPC-HC. This method is completely non-destructive for the original files. However, these source filters were not designed for playback and require a really fast processor for realtime playback of HD video.

So, I want to use a DirectShow filter to do this, but the ones I've tried do not playback the streams at the correct speed. Even when I apply an IVTC filter like tfm().tdecimate(), the speed is all messed up.

For example, try playing in MPC-HC the following avs file (where video.m2v is any 3:2 telecined stream):
a=DirectShowSource("video.m2v").tfm().tdecimate()
b=DirectShowSource("audio.ac3")
AudioDub(a,b)the video will play at the wrong speed

[osgZach]

I'm not purporting to know beyond a shadow of a doubt, but exactly how is setting an audio delay tag in a container file destructive to the actual source?

[Inspector.Gadget]

A simple telecine operation (and its inverse) won't mess with the audio synch between a video stream and the accompanying audio stream; the playback speed of the video stream is measured in FPS, where the number of seconds is constant and new frames are inserted and just played back more quickly. I suspect that since you're using DirectShowSource the reason you're experiencing desynch is that your DirectShow MPEG-2 decoder (like, for instance, ffdshow) has the option to discard pulldown flags or smooth timestamps, and you're applying the IVTC to a video that isn't the same as the original.

[asc28]

I'm not purporting to know beyond a shadow of a doubt, but exactly how is setting an audio delay tag in a container file destructive to the actual source?AFAIK no audio delay tag feature exists for mkv and avi containers, it just cuts the audio track when you add delay. does anyone know about ogm?

someone just notified me that transport streams do not cut the audio destructively so i'm looking into that now

[Inspector.Gadget]

You're incorrect. AviMux GUI does non-destructive delay for audio in AVI, MKVMerge for MKV, and other apps have similar capabilities. Transport streams and program streams muxers can do it too. Hell, even ASF can do it.

You should also look into what I said about proper (inverse) telecining. It doesn't change the display length of the video at all.

[asc28]

A simple telecine operation (and its inverse) won't mess with the audio synch between a video stream and the accompanying audio stream; the playback speed of the video stream is measured in FPS, where the number of seconds is constant and new frames are inserted and just played back more quickly. I suspect that since you're using DirectShowSource the reason you're experiencing desynch is that your DirectShow MPEG-2 decoder (like, for instance, ffdshow) has the option to discard pulldown flags or smooth timestamps, and you're applying the IVTC to a video that isn't the same as the original.playback is not in sync with or without IVTC. i believe it simply can't detect the framerate of elementary streams. and AssumeFPS doesn't fix it

alternatively the DirectShow filter could be ignoring pulldown flags which would be fine but it still plays at 29.97 (it seems to be misdetecting the length of files). I've tried Microsoft's MPEG2 decoder, Gabest's, and ffmpeg/ffdshow, currently testing DScaler's MPEG2 decoder

[edit] I'll look into AVI some more, but I'm pretty positive about MKV and mkvmerge. What would be great is if a container that supported FLAC had delay tags. Please let me know

[Inspector.Gadget]

You are incorrect about mkvmerge. Do the following: take a short FLAC file of your choosing. Decode it to a WAV file. Take the original FLAC, mux to mkv with any delay value using mkvmerge, then demux to a differently named flac file with mkvextract. Then decode that flac to wav and compare it to the wav created from the original FLAC. They are bit-identical.

[nurbs]

Inspector.Gadget is right. Also you can't necessarily correct audio delay by cutting samples, at least not with lossy codecs. They have frame sizes of several milliseconds, so you could only cut multiples of that.

[asc28]

Did the test and you guys were right and even used mkvinfo to see where the delay is in the container. Don't know how I went so long without knowing this. It's strange because I could've sworn that when I used mkvextract in the past, the delay was preserved in the demuxed audio. Sorry about the confusion

[edit] It's negative delays that cut into the data. Knew about this before but forgot.