Choppy output from FFmpeg

[Quaraxkad]

I'm converting a H.264 TS video with FFMPEG. The video always ends up choppy. This is the output from encoding the first 5 seconds, some lines removed for length:

ffmpeg.exe -i "c:\videoin.ts" -f avi -an -t 5 -vcodec mpeg4 -b 12960k -v 3  "C:\videoout.avi"

Input #0, mpegts, from 'C:\videoin.ts':
  Duration: 01:31:55.3, start: 38704.550067, bitrate: 15745 kb/s
  Stream #0.0[0x31]: Video: h264, yuv420p, 1920x1088, 25.00 fps(r)
  Stream #0.1[0x34]: Audio: ac3, 48000 Hz, stereo, 384 kb/s
Output #0, avi, to 'C:\videoout.avi':
  Stream #0.0, 1/90000: Video: mpeg4, yuv420p, 1920x1088, 1/25, q=2-31, 12960 kb/s, 25.00 fps(c)
Stream mapping:
  Stream #0.0 -> #0.0
Press [q] to stop encoding
*** 19 dup!
*** 3 dup!
*** drop!
*** 1 dup!
*** drop!
*** 1 dup!
*** drop!30 q=2.0 size=     373kB time=1.2 bitrate=2545.7kbits/s dup=28 drop=2
*** 1 dup!
*** drop!
*** 1 dup!
*** drop!39 q=2.0 size=     492kB time=1.6 bitrate=2584.4kbits/s dup=32 drop=4
*** 1 dup!
*** drop!
*** 1 dup!
*** drop!
*** 1 dup!9 q=1.6 size=     606kB time=2.0 bitrate=2534.0kbits/s dup=36 drop=7
*** drop!
*** 1 dup!
*** drop!
*** 1 dup!
*** drop!60 q=2.0 size=     623kB time=2.4 bitrate=2127.4kbits/s dup=42 drop=9
*** 1 dup!
*** drop!
*** 1 dup!
*** drop!
*** 1 dup!9 q=2.0 size=     735kB time=2.8 bitrate=2181.6kbits/s dup=46 drop=12
*** drop!
*** 1 dup!
*** drop!
*** 1 dup!
*** drop!
*** 1 dup!9 q=2.0 size=     849kB time=3.2 bitrate=2200.4kbits/s dup=52 drop=15
*** drop!
*** 1 dup!
*** drop!
*** 1 dup!
*** drop!90 q=2.0 size=     964kB time=3.6 bitrate=2194.0kbits/s dup=58 drop=17
*** 1 dup!
*** drop!
*** 1 dup!
*** drop!
*** 1 dup!9 q=2.0 size=    1077kB time=4.0 bitrate=2227.8kbits/s dup=62 drop=20
*** drop!
*** 1 dup!
*** drop!
*** 1 dup!9 q=1.6 size=    1191kB time=4.4 bitrate=2238.1kbits/s dup=66 drop=22
*** drop!
*** 1 dup!
*** drop!
*** 1 dup!
*** drop!20 q=2.0 size=    1208kB time=4.8 bitrate=2061.8kbits/s dup=72 drop=24
*** 1 dup!
*** drop!
*** 1 dup!
frame=  126 q=2.0 Lsize=    1326kB time=5.0 bitrate=2155.5kbits/s dup=76 drop=26
video:1015kB audio:0kB global headers:0kB muxing overhead 30.612374%

I know dup means it's a duplicate frame and drop means it's dropping a frame. It's dropping frames it shouldn't be though, which is messing up the resulting video. Why is it dropping the wrong frames? I also tried encoding this video with MEncoder and the output is smooth, but it crashes every time it reaches a certain frame.

[45tripp]

perhaps you should try uploading a sample clip that includes the problem area somewhere,
so someone might give it a try.

[Soopafresh]

Here's an alternate way to encode, see posts starting with march 5th

https://forum.videohelp.com/viewtopic.php?t=323601&postdays=0&postorder=asc&start=30

You can modify the batch files to use ffmpeg instead of HCenc - you can probably use the same syntax that you have posted above, just use the Test.AVS file as your input source and make sure your ffmpeg.exe is dated after Sept 2006 for Avisynth support.

[Quaraxkad]

perhaps you should try uploading a sample clip that includes the problem area somewhere,
so someone might give it a try.

I figured a sample clip would help, but even a very short sample is pretty large. It's 1080i at about 15Mbps. I tried anyway and pretty much every program I tried has a different problem with the video.

[Quaraxkad]

Here's an alternate way to encode, see posts starting with march 5th

https://forum.videohelp.com/viewtopic.php?t=323601&postdays=0&postorder=asc&start=30

You can modify the batch files to use ffmpeg instead of HCenc - you can probably use the same syntax that you have posted above, just use the Test.AVS file as your input source and make sure your ffmpeg.exe is dated after Sept 2006 for Avisynth support.

I tried the samples you posted in your other thread. After dumping the video with MPlayer, I used MP4Box:

MP4Box.exe -add D:\video.h264 -new d:\video.mp4
Cannot find H264 start code
Error importing D:\video.h264: BitStream Not Compliant

If I skip that part and load the TS directly with AVISynth, there is no video output.

I scanned the file with Mpeg2Repair, no errors. Scanned it wth TS Packet Editor, no errors. ProjectX only gets the audio when demuxing. DGIndex says "No video sequence header found!" when manually selecting the PIDs. Xport outputs empty files.

I am going to try to get a sample clip again...

[Soopafresh]

Must be your source file. You can't use DGindex on an H264 TS file. Use the DGavcindex app I included in the 30MB download instead.

[Abond]

If I skip that part and load the TS directly with AVISynth, there is no video output.

What you mean "directly"?

[Quaraxkad]

Must be your source file. You can't use DGindex on an H264 TS file. Use the DGavcindex app I included in the 30MB download instead.

I'm uploading sample clips right now. While I'm waiting for those, do I use DGAVCIndex on the .h264 output from MPlayer?

[Soopafresh]

Yes.

Upload a portion of TS file.

[Quaraxkad]

If I skip that part and load the TS directly with AVISynth, there is no video output.

What you mean "directly"?

I meant loading the TS file instead of the MP4 output from the batch file Soopafresh made.

directshowsource("video.ts",fps=25.0)

[45tripp]

I'm uploading sample clips right now. While I'm waiting for those, do I use DGAVCIndex on the .h264 output from MPlayer?

Yes.
DGAVCindex only works with elementary h264 streams.
Note:
If it's PAFF don't bother.
Also I think Soopafresh includes version Alpha2 with his batch files. Version Alpha3 is now available.

[Soopafresh]

I updated the batch file to stop using MP4s. The Rev2 zip files use DGavcsource("yourfile.dga")

45tripp is absolutely right - if the file is PAFF/interlaced, you'll have to wait for technology to progress.

Yes, Alpha 3 has been released. I've hesitated including it because it is a bit more complicated for the "uninitiated"

[Quaraxkad]

Yes.

Upload a portion of TS file.

Here is a peice of the TS file. I used CutFile to get it.
http://www.bestsharing.com/files/rQ1M5X248198/source.ts.html

I also have a quick generic MPEG4 encode of that so you can see that it has duplicate frames where the source does not, but it won't upload!

[Soopafresh]

Downloading....

Works fine with my batch.

output.m2v

[Quaraxkad]

Here's that MPEG4 encode... It's a little messed up at the beginning, I assume it's because the source was an incomplete file fragment from CutFile.
http://www.bestsharing.com/files/3gSnn248201/output.mp4v.avi.html

[Soopafresh]

Remember, to process your file, rename it to INPUT.TS and place it in the same folder as the enc2mpeg2_NEW_R2 files. It needs cropping on both the top and bottom, so edit the batch with

crop(0,32,-0,-32)

out.avi

[Quaraxkad]

Remember, to process your file, rename it to INPUT.TS and place it in the same folder as the enc2mpeg2_NEW_R2 files. It needs cropping on both the top and bottom, so edit the batch with

crop(0,32,-0,-32)

out.avi

I came across this problem while testing a GUI I'm writing for FFMPEG (just for my own use, unless it ends up being good...). Is there something wrong with the source file that is making FFMPEG mess up the output? What's with all the dropped frames?

I haven't tried it with your batch files, but I did each step manually.

A re-cap of all the problems with the video...
The video plays (slowly, thanks to my slow computer and H.264) in MPC, MPlayer and VLC.
FFMPEG produces choppy output with duplicated and missing frames (noticable while playing and frame-stepping)
MEncoder crashes at the same location every attempt, but the output is smooth
Mpeg2Repair shows no errors in audio or video
TS Packet Editor shows no errors in audio or video
ProjectX only demuxes the audio portion
Xport runs for a while, can't tell if it's actually doing anything but I end up with 0-byte files.

>xport.exe "video.ts" 1 1 1
xport Transport Stream Demuxer 0.93
program = 1, video channel = 1, audio channel = 1
Program Number = 3 (0x0003), Program Map PID = 48 (0x0030)

packets for pid    0 <0x0000> = 11616, first = 1, last = 57738551
packets for pid   48 <0x0030> = 11616, first = 2, last = 57738552
packets for pid   49 <0x0031> = 56275614, first = 3, last = 57741257
packets for pid   52 <0x0034> = 1442411, first = 79, last = 57741243
coded frames = 0, video fields = 0

MPlayer dumps the video with an error (I think it's an error...) at the end: "TS_PARSE: COULDN'T SYNC"
DGAVCIndex runs through that whole .h264 file in a few minutes and then shows an error message at the end: "slice_qp_delta makes slice_qp_y out of range"

After that I try this AVS... (essentially the same as the batch file output without the extra cropping/sharpening/etc)

setmemorymax(768) 
loadplugin("dgavcdecode.dll") 
avcsource("video.dga") 
converttoyv12()

And there is no video in any player.

I am going to try letting TS Packet Editor cut out the parts I don't want and try again with that file.

[Quaraxkad]

Ok, I made a stupid mistake... I had xport.exe set on program 1, but it should have been program 3. DGAVCIndex worked without an error on this file. When playing the same AVS file in MPC, it says "AVCSource: Could not open one of the input files."

[Soopafresh]

The problem with Mencoder or FFmpeg on h264 transport streams is that the support is new and still fairly buggy. It isn't so much with the apps, but rather the variation in TS files out there. With Mencoder, you can try telling the encoder to stop dropping frames by adding

-Noskip


to the encoding line, but this won't stop the drops in every case. Still, I've been able to transcode a 2 hour long movie from h264 into Xvid via Mencoder and it worked perfectly. Unfortunately, this has been the exception rather than the rule.

The second problem with mencoder doing the demuxing is that it starts on the first frame, so if the data isn't perfect, you can expect A/V sync errors when muxing the file back together. That's the advantage in using Xport.exe - the app demuxes both the audio and video on the first video I frame.

Have a look at the batch procedure for some ideas. The steps are the same -

1) Automatically running Mpeg2repair and creating a "fixed" .TS file
2) Running Xport on the Fixed TS file, demuxing to .h264 and .ac3
3) Indexing the .h264 file with DGavcIndex.exe for processing in Avisynth

What you'd want to do is replace Step 3 with Muxing the raw .h264 into an .MP4 container via Mp4box.exe

Then, run ffmpeg.exe against the .Mp4 file, and process the audio separately. You can't put an AC3 file into an MP4 container, so you either need to convert it into Mp3 or AAC

Your file does work, as demonstrated.

Rem - Fix small errors in transport stream. Input file is Input.ts
mpeg2repaircli /R output.ts input.ts
Rem - Note, the mpeg2repaircli does require .Net 2.0 to work


Rem- Run Xport on fixed file
Xport.exe output.ts 1 1 1

Rem - Rename output files to proper extensions
ren bit*.mpv output.h264
ren bit*.mpa output.ac3

Rem - Mux h264 video into Mp4 container
Mp4Box -add output.h264 output.mp4

Rem - Transcode Video with ffmpeg or Mencoder
ffmpeg -i output.mp4 -croptop 32 -cropbottom 32 -vcodec xvid -b 3200 -y VIDEO.avi

Here's your file, I added -s 720x400 to make it small enough to post here. But, you can see the above works fine, and you can skip having to go through Avisynth (although there's some visual improvements that you can only get with Avisynth).

output400.avi


If you want to play HD h264 without stuttering, you need the CoreAVC decoder, with the Haali media splitter.

[Quaraxkad]

With Mencoder, you can try telling the encoder to stop dropping frames by adding

-Noskip

to the encoding line, but this won't stop the drops in every case.

I don't think MEncoder is dropping any frames, just FFMPEG. The problem with MEncoder was that it crashes every time it reaches a certain point in the video.

1) Automatically running Mpeg2repair and creating a "fixed" .TS file

I was under the impression that if the MPEG2Repair log showed no errors, that the output file would be identical to the input. Is that not correct? I've been skipping that step because it adds a lot of time that I thought was redundant.

What you'd want to do is replace Step 3 with Muxing the raw .h264 into an .MP4 container via Mp4box.exe

Then, run ffmpeg.exe against the .Mp4 file, and process the audio separately. You can't put an AC3 file into an MP4 container, so you either need to convert it into Mp3 or AAC

If I want to preserve the original AC3 audio in an AVI container, should I still use DGAVCIndex on the .h264 and then AVISynth into FFMPEG? Does FFMPEG support AVS input? Not a major problem anyway, I can just use MP4Box and then use VirtualDub to mux the video and audio into AVI.

[Soopafresh]

Mpeg2repaircli will change the PIDs inside the transport stream file, removing all but the audio and video channels. Doing this allows you to blindly run Xport with the 1 1 1 parameters, ensuring you've caught the correct channels when you demux. It is worth the processing time, seriously.

No need to use DGavcindex if you decide to mux the h264 into an mp4 via mp4box.

You can mux the XVID (or whatever output) with the AC3 via ffmpeg like this

ffmpeg -i video.avi -i output.ac3 -vcodec copy -acodec copy -y "FINAL_MOVIE.AVI"


Finally, a note regarding dropped frame with ffmpeg - the revisions vary greatly - everything from Sept 2006 to present day is different, and there is a new revision released at least once a month. Once you find a version that works, hold onto it

BTW, does your encoding always stop when the output file reaches 2GB ?

[Quaraxkad]

If you want to play HD h264 without stuttering, you need the CoreAVC decoder, with the Haali media splitter.

I actually tried CoreAVC but didn't find it to be any faster than the version of FFDShow I'm using.

[Quaraxkad]

BTW, does your encoding always stop when the output file reaches 2GB ?

No, that's never happened to me before.

[Quaraxkad]

Your batch file worked up until HCEnc, which only encoded the first 373 frames. FFMPEG worked fine on the AVS file though. Can I shorten the process by having AVISynth load the TS file instead of demuxing first?

[Quaraxkad]

New problem... FFMPEG and MEncoder both crash when muxing the avi and ac3. It worked in VirtualDub (Direct Stream Copy), but the video played too fast even though it was still 25fps. It also thought the AC3 file was 2 hours and 7 minutes, and it should have been 1 hour and 31 minutes.