VirtualDub/Directshowsource() and H.264 TS files producing grey frames at output

[Booker]

Hi guys,

I've been trying to work with multiple HD H.264 TS files for a few days and it has proved to be more difficult to work with than I thought.

1) I've tried to join h.264 TS files using command prompt's binary copy /b and it just doesn't work. The video won’t even play at all. It seems to work fine for normal MPEG2 ones though. Any particular reason for this phenomenon happening?

2) Since I can't join them using them using the /b command, I thought of using this:DirectShowSource("a.ts") + DirectShowSource("b.ts").... etc


However, using DirectShowSource(), there always seem to be a few grey frames at the beginning of the video, as well as at the end of it. (Note: It applies to single files as well. The example shown above is what I did to concatenate multiple files together.)

The grey frame produced could differ when muxed with different containers (AVI (I know it’s a no-no but still I had to try it)/MP4/MKV).

Normally, there will be a few grey frames at the beginning i.e., Frame 0-7, as well as the last few frames at the end.

Sometimes, the grey frame doesn't appear at the start of the output. (i.e., Frame 10, frames 0-9 are alright)

I thought it might be the splitter or decoder problem, so I've tried different splitters, namely Haali's media splitter and HDTVpump, and even Nero splitter. Same thing, grey frames produced.

Similarly, I thought it might be the decoder problem so I tried using PowerDVD as well as FFDShow. Still, the same thing happened.

My last thought could be that the TS files do not start a key frame, so, I've decided to cut at a key frame using HDTVpump but the exact same thing happened.

I've tried to re-mux them to MKV/MP4 but I am having problem with seeking and audio sync so I'll pass on that one for now. (Output has grey frames too)

Then, I decided to load up some MPEG2 files(remuxed from the TS) using Directshowsource() and I realised the same thing happened too. Grey frames produced at the start and the end. But of course, using DGDecode, I don't see these grey frames but it doesn't work for H.264 TS files.

The funny thing is, the number of frames at the output using DGdecode and DirectshowSource differed by quite a bit.

(For example, using DGDecode I've got 100,000 frames, without any grey frames produced. However, when DirectShowSource is used, there are only 99,990 frames, including the grey frames.)

Naturally, my audio and video would be out of sync when remuxed and this is such a headache :(

Can anyone help me out?

Thanks. :cool:

[friends-fan]

i noticed those too and could pinpoint em to the latest avisynth version i just upgraded to (2.5.7 RC1). I then went back to 2.5.6a and the grey frames where gone.

As you didnt state the avs version u use, not sure if that was helpful at all ;)

[Booker]

I'm currently using 2.5.7 too. I used to use 2.5.6 but I'm not sure what build it was but there was the grey frames too.

[Booker]

Damn. I've just tried 2.5.6a and I realised that the grey frames at the start are gone. But, the grey frames at the end are still there.

So, I went on to try some other older versions, and true enough, there wasn’t any grey frame anymore. One bad thing though, the last few frames just freeze at the last render-able frame, meaning to say that the last few frames are essentially junk.

Any help on this one? :(

[Wilbert]

So, I went on to try some other older versions, and true enough, there wasn’t any grey frame anymore. One bad thing though, the last few frames just freeze at the last render-able frame, meaning to say that the last few frames are essentially junk.
Yes, it's a known issue. It's not a bug of AviSynth, but we are still thinking about a satisfactory solution:

The problems is DirectShow doesn't deliver a frame, it just hangs. I added code to implement Timeouts instead of hanging forever, but I now have the problem of what to do with the failure. Currently the options are a "Grey Frame" or a runtime Exception, neither of which I am really happy with.

Most of the problems appear to be deadlocks in some non-descript spliter. AVS is probably more a victim of this because it builds 2 separate graphs, one for audio only and one for video only rather than a single graph that renders both audio and video and plays them synchronously. (Remember AVS GetFrame() and GetAudio() are independantly asynchronous)

link: http://forum.doom9.org/showthread.php?p=886725#post886725

[IanB]

I am starting to suspect a different pathology to this complaint.

Any change of getting a DirectShowSource log spanning these events?...
DirectShowSource(... , logfile="blah.log", logmask=-1) # 2.5.7 feature!
...Just open the script, access the appropriate 10 to 15 frames and close it. Don't encode up a 2 hour beheamoth, a gigabyte of log file is useless, they grow very quickly.

[Booker]

Hi there,

The log is attached below. I've encoded the last ~15 frames whereby the frames become grey.

[G_M_C]

IanB, have you had time to look at this problem ? (Because there never was an answer given in this thread ;) ).

Also i seem to have the same problem (my question-thread (http://forum.doom9.org/showthread.php?t=118101))), only the frames dont flash grey at the beginning, they flash allmost all the time (irregular, restaring video will give other pattern/speed of flashing, and in some rare cases no flashing at all).

[Booker]

The grey frames are such a headache. I've quite a few H.264 TS files waiting to be encoded but there's still no satisfactory solution that would solve the problem. :(

[G_M_C]

The grey frames are such a headache. I've quite a few H.264 TS files waiting to be encoded but there's still no satisfactory solution that would solve the problem. :(

Yeah, and the DSS () filter will get used more often in the future, because more stuff gets released in H264 format. And the only way to get that stuff trough AviSynth is DSS ().

Alternatively, there was some suggesion of a MP4source ()-command a while. But that idea was rejected, dont remeber why. But i would be a usefullcommand none the less, for the same reasons; MP4/H264 etc. will get used more and more ...

So lets hope for a soultion to the DSS () problem (and rejoice even more if someone invents a MP4Source()-filter) ;)

[Wilbert]

Until this is solve you can make a script which detects grey frames and replaces them with previous non-grey frames. If nobody can make such a script, i will make on this weekend.

[Booker]

Hi there,

How about this part
Then, I decided to load up some MPEG2 files(remuxed from the TS) using Directshowsource() and I realised the same thing happened too. Grey frames produced at the start and the end. But of course, using DGDecode, I don't see these grey frames but it doesn't work for H.264 TS files.

The funny thing is, the number of frames at the output using DGdecode and DirectshowSource differed by quite a bit.

(For example, using DGDecode I've got 100,000 frames, without any grey frames produced. However, when DirectShowSource is used, there are only 99,990 frames, including the grey frames.)

Naturally, my audio and video would be out of sync when remuxed and this is such a headache


whereby the number of frames differ? Is there any viable solution to this? :confused:

[G_M_C]

Until this is solve you can make a script which detects grey frames and replaces them with previous non-grey frames. If nobody can make such a script, i will make on this weekend.

I've also gone back to v2.56a yesterday and the grey frames were gone; At least at the start of the clip.

Havent looked at the end of the clip though, but most of the times its not that big of a problem (because the end of the clip contains the end-credits in most of my cases, and missing a few frames there is not really a problem to me :p )

But a small patch for the problem is not a bad idea; Not everybody is willing/able to go back a version.

[huang_ch]

Just see this thread, and I've also met this problem with v2.57 rc1 while encoding a xvid video, but not all video have this problem....

[IanB]

I've looked at Booker's log and I've commited a fix based on this for one of the causes for grey frames at the beginning. I also have a plan to change the frame buffer handling so I can fill in grey frames at the end with the last good frame, but it will take some time to rewrite that code.

In the meantime I am still waiting for a log for grey frames in the middle of a clip.

[G_M_C]

I've looked at Booker's log and I've commited a fix based on this for one of the causes for grey frames at the beginning. I also have a plan to change the frame buffer handling so I can fill in grey frames at the end with the last good frame, but it will take some time to rewrite that code.

In the meantime I am still waiting for a log for grey frames in the middle of a clip.

As i posted earlier, I could manage with going 1 version back, and have made my transcode. To free up some some HD-space I deleted the original source (since i was ready with it, and video-stuff requires too much HD space allready :p ).

But a very similar project will start in the next few day's, i'll try to post a log of DSS () / some grey frames from 2 or 3 places (including the end) of that clip.

[Fulcanelli123]

I have the same problem...not just grey frames but duplicates. It's very weird because it doesn't always behave the same way.

I thought I'd solved it by splitting the file halfway before frameserving, and then stitching them together in ProCoder. It seemed to do the trick. Last week though, I got duplicates at the 'join point' which never happens with none h.264 files. No biggie, I cut those frames and it was fine.

However, a cap I did last night (same programme as the previous ones), not only had grey frames at various points, but frames were in the wrong order (got the last 10 minutes appearing at the 16minute point as well as it's proper place. The part that should have shown at 16 minutes has vanished.) Tried it without splitting and got exactly the same result. Strangely the file length of 46.10 reads the same, but it just seems to have arbitrarily decided to move frames around.

I'm gonna have to give up using AVS with H.264 files until the problem is fixed. :(

[Pookie]

Mencoder seems to work well with straight .TS h264 file input. I used Winmenc to create the batch file, then tweaked it a bit to my liking. Xvid output looked great, and the audio was in perfect sync. It is only a matter of time until the Avisynth issue gets fixed, until then... http://winmenc.blogspot.com/

[Fulcanelli123]

Mencoder seems to work well with straight .TS h264 file input. I used Winmenc to create the batch file, then tweaked it a bit to my liking. Xvid output looked great, and the audio was in perfect sync. It is only a matter of time until the Avisynth issue gets fixed, until then... http://winmenc.blogspot.com/


I must try that, thanx!

I encode SVCD but it's been very hit and miss so far. I think if I can manage to get the TS into an avi, then get it into VDub/AviSynth that way, that'll solve a lot of probs.

Saving the TS as an avi via VDub/AviSynth didn't work - got a 26gig file with the grey/duplicate frame problem.

Fingers crossed Winmenc will solve things.

[IanB]

Why should I bother to try and fix this problem if none of you will bother to post a log.

Just add a logfile="blah.log" to your DSS call and do an encode. Zip the log file and put it up somewhere.

[Pookie]

IanB - Check your PM.

[Fulcanelli123]

Mencoder seems to work well with straight .TS h264 file input.

Nope this is no good. Winmenc didn't actually do anything except give me the syntax for mencoder, which I pasted into the CLI. The resultant avi file tries to load into VDub but attempts to reconstruct the index. Then it tells me it failed to find a suitable fourcc decompressor. Trying to load it via avisynth said the same thing.

WMP player won't play it and MediaPlayer Classic said it couldn't render some of the pins in the graph:

Stream 0
AVI Splitter

Media Type 0:
--------------------------
AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {10000005-0000-0010-8000-00AA00389B71}
formattype: TIME_FORMAT_NONE {00000000-0000-0000-0000-000000000000}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 0

----------------------------

I've got plenty of fourcc codecs installed but this new avi file doesn't appear to like any of them.

So looks like mencoder won't be solving my problem. :(

[Pookie]

To Make a 1 Pass Xvid Transcode: (Change the last portion from "input.ts" to the actual name of your TS file)

mencoder.exe -vf-clr -pp 0 -tsprog 0 -vf scale=640:352,harddup -sws 9 -force-avi-aspect 1.818 -ovc xvid -xvidencopts vhq=1:fixed_quant=3:nopacked:trellis:nogmc:noqpel:nocartoon:bvhq=0:max_bframes=2 -oac mp3lame -lameopts preset=320 -o "output.xvid.avi" "input.ts"

To Make a 1 Pass h264 Transcode: (Change the last portion from "input.ts" to the actual name of your TS file)

mencoder.exe -vf-clr -pp 0 -tsprog 0 -vf scale=640:352,harddup -sws 9 -force-avi-aspect 1.818 -ovc x264 -x264encopts bitrate=1900:cabac:qp_constant=12:8x8dct:i8x8:bframes=2:cqm=flat:subq=5 -oac mp3lame -lameopts preset=320 -o "output.264.avi" "input.ts"

[Fulcanelli123]

Nope, either of those options seem to re-encode them. I'll then have to re-encode to svcd (I send to US friends). If I have to encode to xvid>svcd I'm losing a generation and it's not worth the effort.

I went for a straight copy to output in an avi container which I'd heard mencoder could do. (Couldn't save out as an avi in VDub because the only way to get the ts in there was via avisynth and it's messing with the frames.)

Also tried avc>avi with the same results as mencoder. An avi with a missing index, and according to GraphEdit avisplitter can't find the first pin in this new avi. This has got me beat.

The weird thing is Procoder will take the file directly and encode in sync (though I've only tried a 10 minute segment so maybe it'll fall over later). However, without going through Avisynth first, it just doesn't look that good. (I get a better copy with the SD and AviSynth.) It'll also take about 15hrs as opposed to 5hrs using Avisynth (and 1hr 50m for SD version).

I really hate AVC files.

I'm really fed up - I got a new card specifically so I could capture from BBC HD. Never ocurred to me I wouldn't be able to use AviSynth or Vdub to encode to SVCD.

Thanks for your help.

[Wilbert]

@IanB,

A related, but (i think) a bit different problem (I used latest CVS DSS):

About the Alexander trailer from this post: http://forum.doom9.org/showthread.php?p=890273#post890273

It's a VFR WMV with a duration of 1:53. Accordingly to the timescodes file wmvtimes.exe produces it has 2359 frames. So the average fps is about 2359/113 = 20.88 fps.

Encoding the following script to XviD:

DirectShowSource("F:\HDTV\WMV\Alexander_Trailer_1080p.wmv", fps=23.976, seek=false, logfile="F:\HDTV\WMV\log2.txt", logmask=-1)
Crop(0, 132, 0, -132)
LanczosResize(848, 352)

results in a clip with duration 1:53 with grey frames at the end. Apperently DSS tries to fetch frames, while there are none left (because the average fps is lower than 23.976), and thus grey ones are returned. Apperently the "trying to fetch" is done till the duration of 1:53 is reached (???). But it should have resulted in a clip with a shorter duration. (Ok, i can also use the framecount option to avoid this ...)

When I read the log file correctly (see attachment), AviSynth gets 2372 non-grey frames, but the WMV clip only has 2359 frames. However the resulting XviD has precisely 2359 non-grey frames, so i guess i misunderstood the log file :)

[IanB]

Grr! WideScreen posts! :angry:

From WMVTimes the last frame, 2358, starts at 113279ms. The time pattern 0, 41, 83, 125 -> 41, 42, 42 indicates approx 24fps source material. Latter the time pattern 917, 959, 1001, 1042 -> 42, 42, 42 is most typical of 23.967fps material.

The directshow duration was 1134910000*100ns, and the frame count was not available.

You specified FPS = 23.976 and no ConvertFPS=True option.

I would expect vi.num_frames = 1,134,910,000 * 23.976 / 10,000,000 = 2721 frames and 2359 of them to have valid content.

From the log, frames 0 to 2358 received valid content and frames 2359 to 2720 had blank frames returned because of end_of_stream.

[IanB]

See this post http://forum.doom9.org/showthread.php?t=118715 for a new DSS.dll

[Booker]

Hi there,

I've just tried using the new DSS.dll and all is well except there's ONE grey frame just before the last few frames. :confused: The beginning has no grey frames though. :p

[Wilbert]

The directshow duration was 1134910000*100ns, and the frame count was not available.
Ok, so i guess i should have used the framecount option in this case?

You specified FPS = 23.976 and no ConvertFPS=True option.

I would expect vi.num_frames = 1,134,910,000 * 23.976 / 10,000,000 = 2721 frames and 2359 of them to have valid content.

From the log, frames 0 to 2358 received valid content and frames 2359 to 2720 had blank frames returned because of end_of_stream.
The problem is worse with this new DSS. Instead of grey frames till the end (which i wanted to avoid), it inserts black frames throughout the clip to get a 2721 frames clip. (Perhaps in the same places as you would get duplicates when using convertfps=true, but i didn't check that.)

For completeness i added the log file again.

@Booker,
I've just tried using the new DSS.dll and all is well except there's ONE grey frame just before the last few frames.
Post your log file.

[IanB]

@Wilbert,

I see nothing wrong in your latest log :confused:

Frames 0 to 2358 received valid content and frames 2359 to 2720 received a copy of frame 2358 because of end_of_stream.

Please try waiting 30 seconds between opening the script and starting to render it. The ASF splitter enforces a rate limit of real time on playing of streams, M$ may have added some nastyness to more strongly enforce this.


One problem I can see in your log is that the ASF splitter you are using is not returning the correct sample end time. This will cause the ConvertFPS function to advance to the next frame prematurely. I already have code to checks for bastard splitters that return end=start+1, looks like I am going to need to add code to check for end=start+10000 (1ms) as well :angry: Longer term it is obvious I am going to have to abandon use of the sample end time value F#@%ing M$.

Strictly interpreting the DirectShow spec this stream should be display as 10ms of frame followed by 31 or 32 ms of black in the gaps.


@Booker,

when you post your log also tell the exact frame number of the grey frame.

@Pookie.

Please try the new .dll