Opened 11 years ago
Last modified 11 years ago
#2114 new defect
corrupt audio stream on dvb recording using mencoder
Reported by: | 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 , 11 years ago
comment:2 by , 11 years ago
Cc: | added |
---|
I record dvb often, please use the following command:
$ mplayer dvb://ZDF -dumpstream
(Both Ctrl-C and kill stop recording)
comment:3 by , 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 , 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 , 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 , 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 , 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).
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.