SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Recently I updated my HTPC to Slackware 14. My first three TV recordings (terrestrial over the air DVB) all went haywire. All three recordings terminated several minutes early and the audio was out of sync with the video. Eventually I narrowed the cause to mencoder, which I have used for several years to record digital TV.
The version provided in the mplayer package in Slackware 14.0 is broken.
I have been using mencoder like this:
mencoder dvb://{station call letters from ~/.mplayer/channel.conf} -oac copy -ovc copy -of avi -endpos {recording period in seconds} -quiet -o {somefilename}.avi
Simple but functional.
Curious about these new bugs, in Slackware 14 I compiled the older mplayer sources I had been using with Slackware 13.1. I verified the early terminations and sync issues were gone.
Reading around the web indicates mencoder no longer is maintained and one day likely will be dropped from the mplayer package. I can continue using my own compiled version of mplayer but the version will be older and more than likely, one day eventually will no longer compile.
Despite the apparent future of mencoder, the web remains filled with examples of using mencoder to record digital TV. I am finding very little about other options. Both mplayer and ffmpeg are supposed to be the eventual be-all replacements for mencoder, but I haven't read anything how to use either in a simple one-liner exactly like mencoder supports recording. Both support some form of streaming but create a ts file.
Fortunately, I discovered mencoder does not have any dependencies on the remainder of the mplayer package or libs and can be used a a stand-alone tool. I tested removing the mplayer package but keeping the old mencoder binary. The old version worked just fine to record. I renamed the file to streamtv to avoid conflicts with the stock Slackware mplayer and installed to /usr/local/bin/.
Can the current mencoder be patched or is my work-around the best option until either mplayer or ffmpeg is updated to fully replace mencoder?
Note: I'm not interested in mythtv and other large-scale projects.
Looks like 'mplayer2' will be the new encoder from what it reads.
I suppose FFMpeg may do what you want. Believe me I'm pissed too. I like 'devedee' for encoding my DVD's but it's got dependencies to mencoder I think.
I was tempted by mplayer2 as I preferred the idea of mplayer linking to the external ffmpeg libraries rather than using an internal copy and this was one of the stated aims of mplayer2, but as soon as I saw that idiotic python based build system I realised the mplayer2 devs didn't have a clue, so I walked away and didn't look back.
If you had read my post you would have noted I already am.
Quote:
I recommend ffmpeg however, because it produces better quality and is less buggy.
If you had read my post you would have noted that ffmpeg is not yet a full like-for-like replacement for using mencoder to record TV streams. Nor can mplayer yet fully replace mencoder. While both ffmpeg and mplayer can stream DVB, both do so only in raw dump form, which must be transcoded, and neither supports self-termination like mencoder does with the -endpos option. Mencoder does the streaming and transcoding in a simple one-liner.
Possibly either mplayer or ffmpeg can replace mencoder in an exact like-for-like manner, if the appropriate options are used, but I'm not an mplayer or ffmpeg guru. I haven't yet found the correct options that duplicates mencoder in the manner I am using. I've searched the web for discussions about the problem to no avail. I only know that the mencoder one-liner I use is popular for recording TV streams as is witnessed by a casual search of the web.
The version of mencoder provided with Slackware is broken. Recompiling that version will not help resolve anything, unless somebody knows of some applicable patches. I don't know the extent of this breakage because I use mencoder only for two tasks: 1) to record TV DVB streams and 2) as a simple editor. Neither of which is now possible because of the sync failures. Older pre 1.1 versions do not have this problem.
I found only one discussion about the problem and no solutions were provided. (I tried -vf harddup with no success.)
Possibly the problem is not mencoder itself but some dependency. I don't know.
I discovered that VLC supports DVB streaming but as I am not a VLC user I haven't yet assembled the pieces to learn whether VLC can replace the mencoder one-liner in a like-for-like manner or how to script such a replacement.
Quote:
That's the one problem with upgrading software. You downgrade your experience.
Which is why I never use the term upgrade. I always update software, which does not guarantee anything is being improved.
I ran across that FAQ while researching the problem. As noted in the final response of the discussion thread I linked above, the original mplayer team also no longer supports mencoder in an active manner although mencoder remains a part of the mplayer package.
Quote:
I generally use tzap (part of the dvb-apps) package for viewing (in conjunction with xine) and recording DVB programmes. Works a treat.
Thanks, but I don't want to watch live --- I have the TV for that. I want to record -- to time-shift and perform minor editing. With that said, using tzap to record is possible but clunky. I do not notice a way for tzap to terminate itself like mencoder can do with the -endpos option.
is your problem with mencoder restricted to DVB TV streams or it appears in the other cases too?
Fair question. I did not know. I had to run several conversion tests before replying, but now I'm leaning toward the problem being only with DVB streaming. I could not replicate the problem with existing files.
I noticed something interesting.
With the pre 1.1 version of mencoder I would always see some "1 duplicate frame(s)!" messages for about the first 8 to 10 seconds of the stream. Thereafter the messages stopped. When I played the recording the audio/video was not in sync for those 8 to 10 seconds but always was fine thereafter. I never thought much about that and just figured mencoder needed about 8 to 10 seconds to "calibrate" itself to the stream. As I always start my recordings early, I never had any need to think much about that sync issue for those first 8 to 10 seconds.
With the newer 1.1 version "1 duplicate frame(s)!" messages continue throughout the recording and the audio/video never syncs.
Quote:
Is there any reason to use mencoder at all? It seems like your just copying the stream into an avi container.
couldn't you just use
mplayer -dumpfile r1.ts -dumpstream dvb://R1
Then
ffmpeg -i r1.ts -vcodec copy -acodec copy r1.avi
Perhaps I could.
Possibly that is all that mencoder is doing, grabbing the *.ts stream and concurrently converting into an avi container. Watching the initial stdout of mencoder indicates the original signal stream is a *.ts file format.
A quick test indicates xbmc, the app I use to watch recordings and other videos, plays the *.ts files just fine. Thus no worries about being able to watch the recordings.
I haven't yet run any full recordings using the mplayer dump, but I seem to recall that *.ts files used more drive space than *.avi. Not a significant challenge as other than perhaps once or twice a year, I seldom save recordings. Watch once and then delete.
As I rarely save recordings, the ffmpeg conversion probably is unnecessary. For the rare times when I save recordings, often I have to edit the file to rip the commercials, so manually converting to a different container probably is not a big drawback.
One challenge, however. To use *.ts, I'd have to resolve one nice convenience of mencoder: the mplayer dump has no self-termination option like mencoder's -endpos option. I'd have to update my scripts to schedule a kill process event in addition to scheduling the recording. Or perhaps run the mplayer dump inside some kind of timer wrapper.
Any ideas how to best automate terminations?
Although the mplayer dump idea is a possible work-around, the fact remains that the current mencoder is broken with respect to streaming DVB.
The avi shouldn't really be any smaller, since it's still the same mpeg2 encoding inside a different container, it does get changed losslessly, I believe from mpeg_ts to mpeg_ps when put into an avi container, but these are very very similar and should be similarly sized. Sometime ts files can be a problem for some players with FF and rewind and total time, because the ts container does not have an index, index information must be created from the contents of the file and some players don't do this. The avi container would have an index, so can be less problematic in that regard.
Have you tried -endpos with the dumpstream? I'm not sure it would work, but mplayer has an -endpos that works with playback(only play a video for so long), not sure if it would work with dumpstream properly
Interesting that you should raise these topics. With my first test of mplayer dump, a 1 hour recording at 720 resolution, I noticed the audio and video would go out of sync --- when I fast-forwarded. I created an AVI from the TS file and the sync problem disappeared. On the other hand, xbmc had no problem fast-forwarding the TS file and the audio and video remained in sync.
Xine could not play the converted AVI. There was video but no audio. Xine is supposed to support the TS file format yet I could not get xine to play the TS file.
Using the mplayer dump and then trying to convert to an AVI with mencoder results in the same original audio/video sync problems. Thus the problem again seems to be with the original stream and not existing AVI files.
The -endpos option does not work with the raw dump, probably because there is no index.
Right now the easiest solution for me is to keep using the older pre 1.1 version of mencoder. Everything just works with no acrobatics. I can only hope that eventually mencoder is fixed or that mplayer or ffmpeg is updated to replace mencoder dvb streaming in a like-for-like manner. Even if I could pipe the mplayer dump directly to ffmpeg for transcoding to AVI and an index, there still remains the challenge of no support for the -endpos option, which then requires some kind of process kill. Kind of clunky.
You might have less problems if you use ffmpeg to copy the stream into an .mpg container, instead of avi, or try avidemux instead of ffmpeg.
The reason for using avi in mencoder is that's really the only container format it was designed for, so problems can occur with other containers, even though it somewhat supports them.
You could also try and see if the new mencoder works by replacing -of avi, with -of lavf
This will use libavformat to create the avi container.
Last edited by pataphysician; 02-13-2013 at 08:13 AM.
Distribution: Slackware64 14.2 and current, SlackwareARM current
Posts: 1,640
Rep:
Quote:
Originally Posted by Woodsman
Thanks, but I don't want to watch live --- I have the TV for that. I want to record -- to time-shift and perform minor editing. With that said, using tzap to record is possible but clunky. I do not notice a way for tzap to terminate itself like mencoder can do with the -endpos option.
AFAIR this is not right. I remember having used tzap exactly for this, recording. According to the following page it has a timeout option for this: http://www.linuxtv.org/wiki/index.php/Zap
I don't have it installed right now and am not sitting in front of my laptop anyway, but it might be something worth to take a deeper look into. At least for basic recording, not conversion of course.
Last edited by titopoquito; 02-13-2013 at 09:43 AM.
Reason: Typo
Hi,
these are the applications I've chosen for DVB recording and editing:
recording: kaffeine (git version) and VLC
audio/video syncing: ProjectX
editing & conversion: Avidemux
DVD authoring: DeVeDe and Mplayer (just downgraded the 14.0 package to Alien's 13.37 "restricted")
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.