Opened 11 years ago

Last modified 11 years ago

#2114 new defect

corrupt audio stream on dvb recording using mencoder

Reported by: soenke@… Owned by: reimar
Priority: normal Component: mencoder
Version: HEAD Severity: normal
Keywords: Cc: cehoyos
Blocked By: Blocking:
Reproduced by developer: no Analyzed by developer: no

Description

On Gentoo Linux amd64 mplayer version 1.1 the command

mencoder dvb://ZDF -o /home/me/tv.avi -frames 100000 -oac copy -ovc copy

will result in a movie file with a corrupt (too short) audio stream. Hence audio and video stream doesnt match after a few seconds which makes the record unusable.

Workaround: Downgrade mplayer to 1.0rc4

Change History (7)

comment:1 by reimar, 11 years ago

I can't follow your explanation of the issue.
Is the audio corrupt, is it too short or is it just out of sync?
A sample file to test would also help, as well is whether this also happens if you record with mplayer -dumpstream instead, possibly converting this later with mencoder as a separate step.

comment:2 by cehoyos, 11 years ago

Cc: cehoyos@… added

I record dvb often, please use the following command:
$ mplayer dvb://ZDF -dumpstream
(Both Ctrl-C and kill stop recording)

comment:3 by soenke@…, 11 years ago

(In reply to comment #1)

I can't follow your explanation of the issue.
Is the audio corrupt, is it too short or is it just out of sync?
A sample file to test would also help, as well is whether this also happens
if you record with mplayer -dumpstream instead, possibly converting this
later with mencoder as a separate step.

Excuse me but any attempt to attach a short movie file have failed.

Anyway the audio is too short *and* out of sync. Audio and video are in sync only at time 00:00:00. The difference between audio and video grows continuously.

The command mplayer -dumpstream still works (see reply on Comment 2 too).

comment:4 by soenke@…, 11 years ago

(In reply to comment #2)

I record dvb often, please use the following command:
$ mplayer dvb://ZDF -dumpstream
(Both Ctrl-C and kill stop recording)

I use the mencoder command as described above because it is possible to set an execution time limit. This is not possible with mplyer (for unknown reasons). To kill a process instead of controlling its execution time is a dirty hack.

comment:5 by cehoyos, 11 years ago

(In reply to comment #4)

(In reply to comment #2)

I record dvb often, please use the following command:
$ mplayer dvb://ZDF -dumpstream
(Both Ctrl-C and kill stop recording)

I use the mencoder command as described above because it is possible to set
an execution time limit.

But - as you found out - it has the disadvantage that is does not always work (apart from the fact that MEncoder is not an actively maintained application for several years). I suspect remuxing may simply fail at a random point if your reception has a problem and (I don't think this can happen with -dumpstream).

This is not possible with mplyer (for unknown reasons).

To kill a process instead of controlling its execution time is a
dirty hack.

I don't think this is correct, on the contrary it is the right way to stop a dvb recording with mplayer -dumpstream

comment:6 by soenke@…, 11 years ago

(In reply to comment #5)

(In reply to comment #4)

(In reply to comment #2)

I record dvb often, please use the following command:
$ mplayer dvb://ZDF -dumpstream
(Both Ctrl-C and kill stop recording)

I use the mencoder command as described above because it is possible to set
an execution time limit.

But - as you found out - it has the disadvantage that is does not always
work (apart from the fact that MEncoder is not an actively maintained
application for several years). I suspect remuxing may simply fail at a
random point if your reception has a problem and (I don't think this can
happen with -dumpstream).

Not maintained for several years but delivered all the years? This sounds very strange. :|

This is not possible with mplyer (for unknown reasons).

To kill a process instead of controlling its execution time is a
dirty hack.

I don't think this is correct, on the contrary it is the right way to stop a
dvb recording with mplayer -dumpstream

Assume now for a moment you are right. What ever should I do with a dumped ts-file? Of course I can play it with smplayer but I can't edit it so I try to apply the "additional step" recommended by R. Doeffinger. So I make a

$ mencoder -ovc copy -oac copy -o ard.avi ard.ts

with the same defective result.

So there must be an error interpreting ts-data in mencoder.

comment:7 by reimar, 11 years ago

The point of the separate step is that you should be able to easily provide us with a sample file, just in case someone actually has time to try to fix it.
That said, I don't know why you shouldn't be able to edit ts files. Even if you can't, tools like mkvmerge probably will be able to create a nicely packetized file.
One of the problems with your command line is that -oac copy will both create badly muxed AVI files and confuse mencoder's A-V sync algorithm.
If you still want to do that, your best chance is with using -mc 0 -noskip, which I believe the documentation even recommends (not that I think I'd be able to quickly figure out where exactly in the documentation).

Note: See TracTickets for help on using tickets.