Incorrect clip duration upon soundtrack removal or altering

[SamsonovAnton]

I'm not sure whether this forum section is appropriate for my question, because I'm not encoding MPEG2, but only chopping video fragments without re-encoding.


The source of my materials is a digital camcorder which outputs MPEG-PS files, with .mod extension, containing MPEG2 video (SD, 4.5 Mbit/s) and AC3 audio (stereo, 256 kbit/s). When I simply play these files with any software, everything is fine. When I crop them in time domain, using AviDemux and the same output format, everything is still fine. Well, I notice a small difference of reported duration, depending on player software, but this is negligible — only a couple of seconds for a 10-minute video.

But I run into a huge difference when trying to remove original audio: resulting files are reported to be approximately half-length (about 40–60 % of real duration), and are not seekable, or disrupt the sound after seeking.


My first method was to replace the audio track with a pre-generated quiet noise, also AC3-encoded (with FFmpeg). I accomplished this by means of AviDemux's standard function. When playing, SMplayer and VLC report bad duration, confuse at seeking and stop audio after seeking. (I also found that SMplayer isn't able to seek through AC3 soundtrack in a separate file, whether it's an original track or a substituted one.) However, in Media Player Classic and Windows Media Player those video files seem to play well.

My second approach was to use Mencoder instead of AviDemux. The resulting files opened fine at least in SMPlayer, but it was not too long before I discovered that the output format that Mencoder automatically switched to (with some files only, but not with other, which is very strange), was AVI. Because I heard that putting MPEG streams inside AVI container is a bad manner, I forced the format to be MPEG-PS. It produced the most strange files, which SMplayer tried to play at 10x speed without sound.

Then I deciced to get just a raw MPEG video stream. Both AviDemux and Mencoder produce the same result, which have the same problems as the first method: bad reported length, glitchy seeking or no seeking at all. But these files are now causing troubles even in MPC and WMP. The only player that can process such files is VLC: it reports zero length (0:00:00.000), but is able to play and seek without problems.


What am I doing wrong? I've tried several recent versions of aforementioned software, and found no difference in its behaviour, so I believe it's not a bug of software but a feature of MPEG streams or container. Strangely enough, I never heard of any such pitfalls, including numerous FAQs and guides posted here.


PS. I could publish some samples, if needed, but they are obviously large, about 35 MB per minute.

[Emulgator]

What is your destination format ?
.mod (probably coming from tapeless JVC Everio camcorder or Panasonic, or Canon ?)
is reported to be a PITA anyway.

Suggested is renaming extension to .mpg,
Then I would feed it into DGDecode, index and demux to elementary video and audio.
I would get rid of the container under all circumstances.
Then you may cut in MPEG2Schnitt and remux to whatever suits your needs.

[hank315]

@SamsonovAnton
The best way to get help is to post a sample (preferably at mediafire.com), 1 minute (35 MB) will do.

[SamsonovAnton]

Thanks for the replies! I've made plenty of samples of different flavors, and finally even managed to tame the MPEG2Schnitt utility, which gave some food for thought.

Just the facts. AVI header (http://msdn.microsoft.com/en-us/library/aa451195.aspx) stores explicit values of frame rate (dwMicroSecPerFrame) and quantity (dwTotalFrames), so exact clip duration can easily be determined. That's why the aforementioned AVI file, erroneously produced by MEncoder, played well under all circumstances. MPEG headers (http://dvd.sourceforge.net/dvdinfo/) do not seem to represent frame count — just frame rate and bit rate of video stream (sequence header), bit rate and sampling rate of audio stream (AC3 header), and multiplexing bit rate of program (pack header). Therefore, clip duration can only be estimated by bit rate and stream size. This explains that tiny difference in duration reported by different players, even if we watch original clips. My camcorder (Panasonic SDR-H81), being unable to predict video bit rate, always writes video stream bit rate field with a value of 9510 kbit/s and program bit rate as 10'080 kbit/s, while actual rates are around 4600 kbit/s for my usual low-motion videos (7214 kbit/s for high-motion sample) and 256 kbit/s for audio. All the programs I tried before — GOPchop, AviDemux, MEncoder, FFmpeg, and the recently used DGMPGdec, — simply copy the headers without adjusting bit rate fields. (Moreover, MEncoder and FFmpeg put arbitrary garbage in program muxing rate field of container header.) As a result, M2V-files with raw video streams are always reported to have proportionally smaller duration — about 50 % of real length for my usual clips and about 75 % for recent samples — and have troubles with seeking and position displaying. Audio tracks complicate things a bit. On one side, when original clips are played, everything is fine: reported duration, seeking, current position. On the other side, AC3-files with raw audio are not seekable by most players. On the third side, substituting original audio stream with a custom one sometimes produces video clips that are played nicely, while sometimes not, — depending on a combination of remultiplexing utility and playback software. On the fourth side, restoring original audio track always results in again unproblematic files, no matter that software is used for converting or playing. MPEG2Schnitt utility provides “Correct bitrate” option which, in “Average bitrate” mode, helps to normalize video stream bit rate, so even raw stream files are reported to have correct duration and are sought well even in MPlayer (although SMPlayer GUI wrapper still messes current position).Taking all this into account, I conclude that the only solution is to adjust video bit rate field to a proper value. (But I still wonder, why my own sound track is “worse” than the original one.)

This task can be performed by a combination of software: DGMPGdec or similar tool — for splitting original MPEG-PS container into video and audio streams; MPEG2Schnitt — for cutting scenes and adjusting video stream header; (the output configuration dialog — SchnittTool — is quiet confusing, because of its mandatory “Encoder” and “Postprocessing” scripts; luckily, it turns out that video stream is simply copied if no third-party encoders are actually installed, and that post-processing script is just used to select external muxing utility) mplex1 — for helping MPEG2Schnitt to join video and audio streams back again.
MPEG2Schnitt is great, I liked very much its ability to make several cuts at once, in contrast to AviDemux and VirtualDub, which support only one cut. But it requires preliminary splitting of streams, and generates a bunch of auxiliary files all around, — this workflow is too difficult for one that needs to process dozens of clips (20–50). And the worst thing: none of those utilities are portable, they run on Windows only; moreover, at least two of them seem to be abandoned by their developers.

Since I'm used to edit video in Linux, any hint on similar software for Debian, openSuSE or whatever would be appreciated. I think, there is no need for a full-featured editor (this can still be done in AviDemux), but just a command-line utility what corrects MPEG headers with an average bit rate value. Unfortunately, googling for common keywords yields nothing but tons of links to re-encoding topics, which is not my case.