Log in

View Full Version : How to cut h264? -- Trim() doesn't work well here.


mopurist
23rd September 2008, 17:14
OK, so I'm probably just stupid...

I'm using CoreAVC via directshowsource in a script. After finding desired cut points with VDubMod, I use those frame numbers with Trim() to assemble a final video.

The cuts are frame-accurate, but...

Where a new sequence starts in the final video I get a large amount of blocking for a fraction of a second, and sometimes fragments of the video supposedly removed by Trim appear in some of the blocks. The video must be referencing frames that were removed by trim.

Why? As a frameserver, shouldn't the video be completely decoded and then sent as a stream of complete, self-contained frames? Apparently, Trim() doesn't function as I thought it would.

The source videos don't have many I or IDR frames, so h264tscutter doesn't give any better results, plus it is gui-only.

Short of transcoding the video into a huge yuv file and editing that, is there a way to get clean, accurate cuts?

I am doing the transcoding, audio cutting, and merging all via a script on linux running avisynth via avs2yuv. Maybe the problem lies with my setup. Can anyone confirm that they get clean cuts when using Trim() on h264 video with avisynth under windows?

Thanks.

Guest
23rd September 2008, 17:23
Can anyone confirm that they get clean cuts when using Trim() on h264 video with avisynth under windows? Yes, I do, using DGAVCDec and DGAVCDecNV (not DirectShowSource).

mopurist
23rd September 2008, 18:37
Yes, I do, using DGAVCDec and DGAVCDecNV (not DirectShowSource).

Thanks (for this reply as well as all of the work you've put in to all your software).

The last time I tried DGAVCDec, libavcodec didn't yet properly decode these streams. CoreAVC was all that worked. I see now that ffplay built with the latest svn source under linux plays them almost perfectly. I'll have to try it again next time you update it with a newer libavcodec.

From what I gathered, DGAVCDecNV doesn't use libavcodec. I may have to give it a go, but something tells me it won't work well under WINE, and since I don't have a dedicated windows machine, I may be SOL for now.

Alex_ander
23rd September 2008, 19:02
Please enlighten me on DGAVCDecNV (Google fails), or is it for linux?

Comatose
23rd September 2008, 19:04
Check the MPEG-4 AVC board on this forum :p

mopurist
23rd September 2008, 19:05
Please enlighten me on DGAVCDecNV (Google fails), or is it for linux?

http://forum.doom9.org/showthread.php?t=141104&highlight=dgavcdecodenv

Alex_ander
23rd September 2008, 19:06
Thanks.

IanB
23rd September 2008, 22:17
Yes, as it says in the DirectShowSource documentationDirectShow video decoders are not required to support frame-accurate seeking. In most cases seeking will work, but on some it might not.Looks like you have found an example of this.

You may try using the seekzero=true option, this forces DSS to read through all the frames in skipped sections of the input stream instead of seeking. And yes, it may be slower but it will work.

mopurist
24th September 2008, 17:08
You may try using the seekzero=true option, this forces DSS to read through all the frames in skipped sections of the input stream instead of seeking. And yes, it may be slower but it will work.

:thanks::thanks::thanks:

I should have RTFM. It does indeed work. The only issue is that the frame numbers in VDubMod are different with and without seekzero=true, so I have to use seekzero to find the correct cut points. As you can imagine, it is a painfully slow process.

IanB
24th September 2008, 22:19
Well maybe you should give DGAVCDec a go. It at least should give consistent frame numbers so you can quickly update your DSS script cut points.