Wrong duration header when joining .mpg files with cat:

[jccc]

When I try to join a set of mpegs (for example "cat *.mpg > joined.mpg"), the length header is set--incorrectly--to the length of the last video in the set.  So instead of 300 minutes, the video player thinks it's, say, 20 minutes.

I've not seen this issue mentioned anywhere that people suggest this joining trick.  Am I the only one?  Is there a way I can set the length property of the .mpg file after-the-fact?

Maybe I could run it through ffmpeg again with -sameq to keep the same video quality, but I don't want it re-coding the audio either.  (My attempt just now setting the same audio bitrate fattened my file up significantly.)  I just need the correct length to be set.

[saratoga]

When I try to join a set of mpegs (for example "cat *.mpg > joined.mpg"), the length header is set--incorrectly--to the length of the last video in the set.  So instead of 300 minutes, the video player thinks it's, say, 20 minutes.

I'm not sure how MPG works, but I doubt a binary join is going to work very well.  Short of running through the entire file to see how many segments there are, how would you even determine the file length?

[dreamlayers]

If you want to properly join .mpg files, you really need to use software which is designed for that.  Try mpeg toolbox or MPEG Streamclip.

[jccc]

I'm not sure how MPG works, but I doubt a binary join is going to work very well.  Short of running through the entire file to see how many segments there are, how would you even determine the file length?

A Google search for how to join multiple .mpg files returns page after page of suggestions simply to use cat.  Also, the FAQ for ffmpeg (suggested by Rockbox's docs for the .mpg player plugin) itself says to use cat.

The test I mentioned above gave me a fully joined mpg file.  (I can play this video, although different players get confused in different ways by the incorrect length header.)  And running this file through ffmpeg once more (ostensibly unchanged w/ -sameq) even gives me the correct length header, but fattens up my file.

Maybe this isn't the place for me to ask the question.  I guess I'll ask on those forums that mention cat, and I'll try mpgtx, but I'd rather not have to install/set up and use yet another custom tool in the chain for doing this.

[Llorean]

Instead of using sameq, have you tried using the "copy" codec, to just copy the stream into a new mpeg file? I'm pretty sure sameq decodes and re-encodes which not only takes longer, but as you've noted results in a file size increase.

[dreamlayers]

Unfortunately, the popularity of an answer online doesn't guarantee its accuracy.  These files have timestamps, and cat does nothing about those.  It often seems to work properly because many players are very error-tolerant, but the file certainly isn't correct.

[jccc]

Unfortunately, the popularity of an answer online doesn't guarantee its accuracy.  These files have timestamps, and cat does nothing about those.  It often seems to work properly because many players are very error-tolerant, but the file certainly isn't correct.

These are very strange responses.  I suppose I'll no longer trust rockbox.org or ffmpeg.org, favoring instead more authoritative sources re: encoding video for small mp3 players.

[Llorean]

If you encode with many of the suggested settings here it'll be just fine. Using a tool like "cat" to merge files is very different from encoding.

If you start from a good source you're fine, but trying to use already compressed and possibly split files can often lead to additional difficulties. MPEG is streamable which is more or less why you can cat files together and expect many players (especially those that will accept streamed content) to be able to play it, not necessarily with functional seeking.

If Rockbox can't play the cat'ed file completely through that *may* be a bug, but you shouldn't really expect seeking to work if you've used a tool completely unaware of the format such as cat to merge the files. Instead you'll want something more intelligent to fix the containers.

[jccc]

Instead of using sameq, have you tried using the "copy" codec, to just copy the stream into a new mpeg file? I'm pretty sure sameq decodes and re-encodes which not only takes longer, but as you've noted results in a file size increase.

Aha.  This looks like the right answer (and I was not aware of the "copy" codec option).

Unfortunately this also looks like it may be an active bug in ffmpeg:
https://roundup.ffmpeg.org/issue807

Using "-acodec copy" works, but gives me the same fattened file.  Using "-vcodec copy" (with or without the former) gives me the error mentioned in that bug report:  "av_interleaved_write_frame(): Error while opening file"

*sigh*

Onward...

[Llorean]

You could try mencoder which I believe also has a copy codec.

This is all a container issue, so anything which can copy the streams and rebuild the container should be good. VLC might also be an option.

[dreamlayers]

Using Mencoder (version Sherpya-MT-SVN-r30521, distributed as a part of Mplayer), the following works for me:

Code: [Select]

mencoder -of mpeg -ovc copy -oac copy inputfile.mpg -o outputfile.mpg

[saratoga]

I'm not sure how MPG works, but I doubt a binary join is going to work very well.  Short of running through the entire file to see how many segments there are, how would you even determine the file length?

A Google search for how to join multiple .mpg files returns page after page of suggestions simply to use cat.  Also, the FAQ for ffmpeg (suggested by Rockbox's docs for the .mpg player plugin) itself says to use cat.

The test I mentioned above gave me a fully joined mpg file.  (I can play this video, although different players get confused in different ways by the incorrect length header.)  And running this file through ffmpeg once more (ostensibly unchanged w/ -sameq) even gives me the correct length header, but fattens up my file.

I didn't ask why you tried to do this, I'm just pointing out that if you think about what you're doing, you'll realize that theres no way it could work