Hi, I want to be able to rip dvd's and play them on my PS3 (and also other future, standards-compliant hardware devices, so this rules out ogg, matroska etc.) The nasty thing is that I also want exactly 1 subtitle track included. Without subtitling it is actually very simple to rip a dvd... I also found out that mp4 does support (soft) subtitling but most devices do not render them, so I will need to render the subtitles in the video stream :-( Also the audio and video need to remain in sync (of course) wich rules out solutions that use elementary streams without a/v sync compensation. As far as I know there is only one combination of programs and options that can do this (see attached script), which works fairly well. It uses the command line versions of x264 and faac to achieve maximum flexibility. The audio and video frames are passed using named pipes so there are no huge intermediate files. The stdin-stdout pipes are only there to keep all processes running while there is still input to be processed, no data is passed through them. It adds chapter info to the mp4 file although the PS3 doesn't use it :-( I was wondering whether someone knows other (simpler) solutions as well. Native subtitling rendering support in ffmpeg and mencoder would the best solution of course, but that's not reality. ============================================== #!/bin/sh audiolang="en" sublang="nl" if [ $# -lt 1 ] then dvd=$PWD else dvd="$1" fi if [ ! -d "$dvd" ] then echo "not a directory: $1" exit fi vpipe1="dvd2avc1.y4m" apipe1="dvd2avc1.apipe" title=$(mplayer -identify -frames 0 -dvd-device $dvd dvd:// 2>&1 | egrep "ID_DVD_TITLE_[0-9]+_LENGTH=" | sort '-t=' -g -r -k 2 | head -1 | \ perl -n -e '($_) = m/ID_DVD_TITLE_([0-9]+)_LENGTH/; print $_') echo "Main title: $title" chapters=$(mplayer -identify -frames 0 -dvd-device $dvd dvd://${title} 2>&1 | perl -n -e 'if(/^CHAPTERS: /) { s/^CHAPTERS: //; s/,/ /g; print $_; last; }') echo "Chapters in this title: $chapters" aid=$(mplayer -identify -frames 0 -dvd-device $dvd dvd://${title} 2>&1 | egrep "ID_AID_[0-9]+_LANG=${audiolang}" | sort -g | head -1 | \ perl -n -e '($_) = m/ID_AID_([0-9]+)_LANG/; print $_') echo "Audio id: $aid" sid=$(mplayer -identify -frames 0 -dvd-device $dvd dvd:// 2>&1 | \ perl -n -e "if(/ID_SID_[0-9]+_LANG=${sublang}/) { (\$a) = m/ID_SID_([0-9])+_LANG/; printf \"%s\n\", \$a; }") echo "Sub id: $sid" avc="dvd.264" aac="dvd.aac" mp4="dvd.mp4" chap="dvd.chap" rm "$vpipe1" "$apipe1" 2> /dev/null mknod "$vpipe1" p mknod "$apipe1" p rm "$chap" 2> /dev/null for chapter in $chapters do echo "$chapter $chapter" >> $chap done mplayer -noconsolecontrols -nocache -vf-clr -benchmark -slang nl -sid "$sid" -aid "$aid" \ -vo "yuv4mpeg:interlaced:file=$vpipe1" -ao "pcm:waveheader:file=$apipe1:fast" \ -dvd-device $dvd dvd://$title 1>&2 /dev/null | \ x264 --bframes 16 --b-pyramid --ref 4 --interlaced --crf 20 \ --trellis 1 --nr 1000 --level 41 \ --threads 2 --direct none --subme 5 -o "$avc" "$vpipe1" | \ (faac --mpeg-vers 4 -b 192 -o "$aac" "$apipe1" 2> /dev/null) rm "$vpipe1" "$apipe1" 2> /dev/null MP4Box -lang en -new "$mp4" -add "$avc" -add "$aac" -chap "$chap" -isma
On Monday 24 March 2008 13:34, Erik Slagter wrote:
Hi,
I want to be able to rip dvd's and play them on my PS3 (and also other future, standards-compliant hardware devices, so this rules out ogg, matroska etc.)
The nasty thing is that I also want exactly 1 subtitle track included. Without subtitling it is actually very simple to rip a dvd...
try http://h264enc.sourceforge.net it has support for the PS3 and MP4 container. Also hardcoding or dumping the subtitle to disk is supported. You can even import the dumped subtitle into the mp4 container
I also found out that mp4 does support (soft) subtitling but most devices do not render them, so I will need to render the subtitles in the video stream :-(
Also the audio and video need to remain in sync (of course) wich rules out solutions that use elementary streams without a/v sync compensation.
As far as I know there is only one combination of programs and options that can do this (see attached script), which works fairly well. It uses the command line versions of x264 and faac to achieve maximum flexibility. The audio and video frames are passed using named pipes so there are no huge intermediate files. The stdin-stdout pipes are only there to keep all processes running while there is still input to be processed, no data is passed through them. It adds chapter info to the mp4 file although the PS3 doesn't use it :-(
I was wondering whether someone knows other (simpler) solutions as well. Native subtitling rendering support in ffmpeg and mencoder would the best solution of course, but that's not reality.
==============================================
#!/bin/sh
audiolang="en" sublang="nl"
if [ $# -lt 1 ] then dvd=$PWD else dvd="$1" fi
if [ ! -d "$dvd" ] then echo "not a directory: $1" exit fi
vpipe1="dvd2avc1.y4m" apipe1="dvd2avc1.apipe"
title=$(mplayer -identify -frames 0 -dvd-device $dvd dvd:// 2>&1 | egrep "ID_DVD_TITLE_[0-9]+_LENGTH=" | sort '-t=' -g -r -k 2 | head -1 | \ perl -n -e '($_) = m/ID_DVD_TITLE_([0-9]+)_LENGTH/; print $_')
echo "Main title: $title"
chapters=$(mplayer -identify -frames 0 -dvd-device $dvd dvd://${title} 2>&1 | perl -n -e 'if(/^CHAPTERS: /) { s/^CHAPTERS: //; s/,/ /g; print $_; last; }') echo "Chapters in this title: $chapters"
aid=$(mplayer -identify -frames 0 -dvd-device $dvd dvd://${title} 2>&1 | egrep "ID_AID_[0-9]+_LANG=${audiolang}" | sort -g | head -1 | \ perl -n -e '($_) = m/ID_AID_([0-9]+)_LANG/; print $_')
echo "Audio id: $aid"
sid=$(mplayer -identify -frames 0 -dvd-device $dvd dvd:// 2>&1 | \ perl -n -e "if(/ID_SID_[0-9]+_LANG=${sublang}/) { (\$a) = m/ID_SID_([0-9])+_LANG/; printf \"%s\n\", \$a; }")
echo "Sub id: $sid"
avc="dvd.264" aac="dvd.aac" mp4="dvd.mp4" chap="dvd.chap"
rm "$vpipe1" "$apipe1" 2> /dev/null
mknod "$vpipe1" p mknod "$apipe1" p
rm "$chap" 2> /dev/null
for chapter in $chapters do echo "$chapter $chapter" >> $chap done
mplayer -noconsolecontrols -nocache -vf-clr -benchmark -slang nl -sid "$sid" -aid "$aid" \ -vo "yuv4mpeg:interlaced:file=$vpipe1" -ao "pcm:waveheader:file=$apipe1:fast" \ -dvd-device $dvd dvd://$title 1>&2 /dev/null | \ x264 --bframes 16 --b-pyramid --ref 4 --interlaced --crf 20 \ --trellis 1 --nr 1000 --level 41 \ --threads 2 --direct none --subme 5 -o "$avc" "$vpipe1" | \ (faac --mpeg-vers 4 -b 192 -o "$aac" "$apipe1" 2> /dev/null)
rm "$vpipe1" "$apipe1" 2> /dev/null
MP4Box -lang en -new "$mp4" -add "$avc" -add "$aac" -chap "$chap" -isma
-- Regards
Grozdan Nikolov (openSUSE Linux) wrote:
On Monday 24 March 2008 13:34, Erik Slagter wrote:
The nasty thing is that I also want exactly 1 subtitle track included. Without subtitling it is actually very simple to rip a dvd...
try http://h264enc.sourceforge.net it has support for the PS3 and MP4 container. Also hardcoding or dumping the subtitle to disk is supported. You can even import the dumped subtitle into the mp4 container
I checked it out, it looks like it's a bit too user-friendly for me. Also I don't think it will actually hard-render subtitles because it only uses mencoder for the video and mencoder cannot hard-render subtitles last time I checked. That's why I use mplayer (with yuv4mpeg output).
On Monday 24 March 2008 19:27, Erik Slagter wrote:
Grozdan Nikolov (openSUSE Linux) wrote:
On Monday 24 March 2008 13:34, Erik Slagter wrote:
The nasty thing is that I also want exactly 1 subtitle track included. Without subtitling it is actually very simple to rip a dvd...
try http://h264enc.sourceforge.net it has support for the PS3 and MP4 container. Also hardcoding or dumping the subtitle to disk is supported. You can even import the dumped subtitle into the mp4 container
I checked it out, it looks like it's a bit too user-friendly for me.
lol, people complain all the time that encoding deals with a lot of parameters and it's hard to do thus it's not user friendly and you come here and complain that it is too user friendly... nice one
Also I don't think it will actually hard-render subtitles because it only uses mencoder for the video and mencoder cannot hard-render subtitles last time I checked. That's why I use mplayer (with yuv4mpeg output).
mencoder can very well hardcode the subtitles into the movie. what are you talking about?? -- Regards
Grozdan Nikolov (openSUSE Linux) wrote:
On Monday 24 March 2008 19:27, Erik Slagter wrote:
Grozdan Nikolov (openSUSE Linux) wrote: I checked it out, it looks like it's a bit too user-friendly for me. lol, people complain all the time that encoding deals with a lot of parameters and it's hard to do thus it's not user friendly and you come here and complain that it is too user friendly... nice one
Ehmm, sorry, but I like things to go automatically and unattended. So I am actually not looking for a complete script but just (rough) combinations of applications/options to achieve what I want.
Also I don't think it will actually hard-render subtitles because it only uses mencoder for the video and mencoder cannot hard-render subtitles last time I checked. That's why I use mplayer (with yuv4mpeg output).
mencoder can very well hardcode the subtitles into the movie. what are you talking about??
The last time I checked, like I said. Some of the guru's on the ffmpeg-devel list claimed this. Probably I was talking about hard-coding the subtitles of a DVD(-stream). I am pretty sure mencoder cannot do that. I have no interest in .sub, .srt, .vobsub, .ass etc. subtitles. What I want is simply DVD -> mp4 with one track of subtitles hardcoded in them (without the use intermediate seperate subtitle files). I believe mencoder cannot do that. I can't use mencoder anyway because although it can generate mp4 files now (using lavf), it cannot handle b-frames at all :-(
On Monday 24 March 2008 19:38, Erik Slagter wrote:
Grozdan Nikolov (openSUSE Linux) wrote:
On Monday 24 March 2008 19:27, Erik Slagter wrote:
Grozdan Nikolov (openSUSE Linux) wrote: I checked it out, it looks like it's a bit too user-friendly for me.
lol, people complain all the time that encoding deals with a lot of parameters and it's hard to do thus it's not user friendly and you come here and complain that it is too user friendly... nice one
Ehmm, sorry, but I like things to go automatically and unattended.
So I am actually not looking for a complete script but just (rough) combinations of applications/options to achieve what I want.
and this shows that you don't understand how h264enc works, or at least didn't get the time to investigate... h264enc supports batch encoding, you can't automate more than that...
Also I don't think it will actually hard-render subtitles because it only uses mencoder for the video and mencoder cannot hard-render subtitles last time I checked. That's why I use mplayer (with yuv4mpeg output).
mencoder can very well hardcode the subtitles into the movie. what are you talking about??
The last time I checked, like I said. Some of the guru's on the ffmpeg-devel list claimed this. Probably I was talking about hard-coding the subtitles of a DVD(-stream). I am pretty sure mencoder cannot do that. I have no interest in .sub, .srt, .vobsub, .ass etc. subtitles. What I want is simply DVD -> mp4 with one track of subtitles hardcoded
and how are you going to insert those subtitles into the mp4 container if not first dumping them to vobsub format and then importing this file into the mp4 container... Do you actually understand what hardcoding of subtitles means? it means it burns them directly into the movie so every time you watch it, you get to see the subtitles and there's no way to get rid of them. That's hardcoding. What you're talking about is called embedding subtitles into a container. This can be very well done with MP4Box but first you have to dump the subtitles to vobsub files and after the encoding is done you import them into the mp4 file on a separate track, so you'll have a video track, an audio track and a subtitles track... this is called embedded subtitles, not hardcoded
in them (without the use intermediate seperate subtitle files). I believe mencoder cannot do that.
I can't use mencoder anyway because although it can generate mp4 files now (using lavf), it cannot handle b-frames at all :-(
-- Regards
Grozdan Nikolov (openSUSE Linux) wrote:
On Monday 24 March 2008 19:38, Erik Slagter wrote:
Grozdan Nikolov (openSUSE Linux) wrote: Ehmm, sorry, but I like things to go automatically and unattended.
So I am actually not looking for a complete script but just (rough) combinations of applications/options to achieve what I want.
and this shows that you don't understand how h264enc works, or at least didn't get the time to investigate... h264enc supports batch encoding, you can't automate more than that...
I am sure h264 is a wonderful application/script, but it's simply not what I am looking for. And indeed, I only had a quick look at the source, to spot how the actual encoding is done. From my past experience with mencoder, which this script indeed appears to use for encoding the video, I don't understand how this can work, other than using intermediate subtitles files (more on this) which I don't want.
and how are you going to insert those subtitles into the mp4 container if not first dumping them to vobsub format and then importing this file into the mp4 container...
I am not going to do that, simple. The PS3 (and probably most other hardware devices) does not support subtitles in mp4. And yes I actually tried it.
Do you actually understand what hardcoding of subtitles means? it means it burns them directly into the movie so every time you watch it, you get to see the subtitles and there's no way to get rid of them. That's hardcoding.
Duh.. Yes, hardcoding of subtitles is actually evil, believe me, if I wouldn't need it, I wouldn't use it. But (again) PS3 leaves me no choice.
What you're talking about is called embedding subtitles into a container.
No, I am talking of hardcoding subtitles into the video stream while transcoding it from mpeg2 video to h264. This must be done at the same time/stage to prevent an extra encoding stage which is unacceptable.
This can be very well done with MP4Box but first you have to dump the subtitles to vobsub files and after the encoding is done you import them into the mp4 file on a separate track, so you'll have a video track, an audio track and a subtitles track... this is called embedded subtitles, not hardcoded
Been there, done that, mplayer handles the subs fine, PS3 ignores them, doesn't work, full stop.
On Monday 24 March 2008 19:56, Erik Slagter wrote:
Grozdan Nikolov (openSUSE Linux) wrote:
On Monday 24 March 2008 19:38, Erik Slagter wrote:
Grozdan Nikolov (openSUSE Linux) wrote: Ehmm, sorry, but I like things to go automatically and unattended.
So I am actually not looking for a complete script but just (rough) combinations of applications/options to achieve what I want.
and this shows that you don't understand how h264enc works, or at least didn't get the time to investigate... h264enc supports batch encoding, you can't automate more than that...
I am sure h264 is a wonderful application/script, but it's simply not what I am looking for.
And indeed, I only had a quick look at the source, to spot how the actual encoding is done. From my past experience with mencoder, which this script indeed appears to use for encoding the video, I don't understand how this can work, other than using intermediate subtitles files (more on this) which I don't want.
and how are you going to insert those subtitles into the mp4 container if not first dumping them to vobsub format and then importing this file into the mp4 container...
I am not going to do that, simple. The PS3 (and probably most other hardware devices) does not support subtitles in mp4.
And yes I actually tried it.
Do you actually understand what hardcoding of subtitles means? it means it burns them directly into the movie so every time you watch it, you get to see the subtitles and there's no way to get rid of them. That's hardcoding.
Duh.. Yes, hardcoding of subtitles is actually evil, believe me, if I wouldn't need it, I wouldn't use it. But (again) PS3 leaves me no choice.
What you're talking about is called embedding subtitles into a container.
No, I am talking of hardcoding subtitles into the video stream while transcoding it from mpeg2 video to h264. This must be done at the same time/stage to prevent an extra encoding stage which is unacceptable.
and you say mencoder can't do that, right? it can't hardcode subtitles? well, everytime i run h264enc, it proves you wrong about this... if you don't specify the -vobsubout option of mencoder, by default mencoder will hardcode the subtitles... period, been there, done that, seen it all... over
This can be very well done with MP4Box but first you have to dump the subtitles to vobsub files and after the encoding is done you import them into the mp4 file on a separate track, so you'll have a video track, an audio track and a subtitles track... this is called embedded subtitles, not hardcoded
Been there, done that, mplayer handles the subs fine, PS3 ignores them, doesn't work, full stop.
-- Regards
Grozdan Nikolov (openSUSE Linux) wrote:
and you say mencoder can't do that, right? it can't hardcode subtitles? well, everytime i run h264enc, it proves you wrong about this... if you don't specify the -vobsubout option of mencoder, by default mencoder will hardcode the subtitles... period, been there, done that, seen it all... over
I'm saying that mencoder cannot hardcode subtitles coming from a DVD (mpeg program stream) while transcoding without the use of several steps involving temporary files holding the subtitles. Mplayer can actually do this, but it cannot transcode at the same time, which annoys me. dvd -> mencoder -> mp4, in one pass, I think that's impossible. My approach (though not the beauty itself) does it all in one pass. If I have some spare time the next days I will have another go at mencoder, if only to remember what exactly was the problem with mencoder and subtitling.
On Monday 24 March 2008 20:08, Erik Slagter wrote:
Grozdan Nikolov (openSUSE Linux) wrote:
and you say mencoder can't do that, right? it can't hardcode subtitles? well, everytime i run h264enc, it proves you wrong about this... if you don't specify the -vobsubout option of mencoder, by default mencoder will hardcode the subtitles... period, been there, done that, seen it all... over
I'm saying that mencoder cannot hardcode subtitles coming from a DVD (mpeg program stream) while transcoding without the use of several steps involving temporary files holding the subtitles. Mplayer can actually do this, but it cannot transcode at the same time, which annoys me.
ok then. So all my DVD (MPEG2 PS) -> H.264 rips with hardcoded subtitles don't actually exist. According to your claim all the rips that I have with hardcoded subtitles are ghost rips and I haven't actually done them? You said that you read somewhere that some ffmpeg dev claimed that it can't be done, so all the physical proof that I have here must be coming from an alternate dimension where it is possible to hardcode subs with mencoder... I don't know where you get your information, but mencoder for sure can do two things - hardcode subtitles - dump subtitles to files in vobsub format
dvd -> mencoder -> mp4, in one pass, I think that's impossible. My approach (though not the beauty itself) does it all in one pass.
If I have some spare time the next days I will have another go at mencoder, if only to remember what exactly was the problem with mencoder and subtitling.
maybe when you tried that you had a bad mencoder/mplayer version. I've seen it before mencoder not willing to hardcode/dump subtitles -- Regards
Grozdan Nikolov (openSUSE Linux) wrote:
maybe when you tried that you had a bad mencoder/mplayer version. I've seen it before mencoder not willing to hardcode/dump subtitles
If you call current svn (always current for me) "bad version" lol. But as said before, mencoder cannot handle B-frames in mp4 (nor any other lavf-container). This can be worked around using elementary streams and then mux using gpac, but this can and will sooner or later screw up your a/v sync because timestamps are lost. That's why I really want to have one single program that does it all in one pass.
On Monday 24 March 2008 20:22, Erik Slagter wrote:
Grozdan Nikolov (openSUSE Linux) wrote:
maybe when you tried that you had a bad mencoder/mplayer version. I've seen it before mencoder not willing to hardcode/dump subtitles
If you call current svn (always current for me) "bad version" lol.
SVN isn't always good, look how they broke the GUI in the SVN
But as said before, mencoder cannot handle B-frames in mp4 (nor any other lavf-container). This can be worked around using elementary streams and then mux using gpac, but this can and will sooner or later screw up your a/v sync because timestamps are lost. That's why I really want to have one single program that does it all in one pass.
then use ffmpeg.... sooner or later, like 250+ rips I've done so far and all of them have b-frames, but none of them have A/V sync issues? if you use your filters in a correct way, I can assure you, you won't get A/V sync issues. MP4Box works just great -- Regards
Grozdan Nikolov (openSUSE Linux) wrote:
then use ffmpeg.... sooner or later, like 250+ rips I've done so far and all of them have b-frames, but none of them have A/V sync issues? if you use your filters in a correct way, I can assure you, you won't get A/V sync issues. MP4Box works just great
I'd really would want to use ffmpeg, it does a great job maintaining a/v sync, b-frames are fine, etc. BUT: no filters (not that big a problem for me and it's being worked on) AND no subtitle rendering (and that is not going to change in the near future). So ffmpeg is not usable for me.
On Monday 24 March 2008 20:32, Erik Slagter wrote:
Grozdan Nikolov (openSUSE Linux) wrote:
then use ffmpeg.... sooner or later, like 250+ rips I've done so far and all of them have b-frames, but none of them have A/V sync issues? if you use your filters in a correct way, I can assure you, you won't get A/V sync issues. MP4Box works just great
I'd really would want to use ffmpeg, it does a great job maintaining a/v sync, b-frames are fine, etc. BUT: no filters (not that big a problem for me and it's being worked on) AND no subtitle rendering (and that is not going to change in the near future). So ffmpeg is not usable for me.
then mencoder/mp4box are the only tools you can use for this. I'm pretty sure that it supports hardcoding the subtitles -- Regards
Grozdan Nikolov (openSUSE Linux) wrote:
I'd really would want to use ffmpeg, it does a great job maintaining a/v sync, b-frames are fine, etc. BUT: no filters (not that big a problem for me and it's being worked on) AND no subtitle rendering (and that is not going to change in the near future). So ffmpeg is not usable for me.
then mencoder/mp4box are the only tools you can use for this. I'm pretty sure that it supports hardcoding the subtitles
I am using mplayer/mp4box and it works. See my original script. I was hoping for a more elegant solution to this.
Erik Slagter wrote:
Grozdan Nikolov (openSUSE Linux) wrote:
maybe when you tried that you had a bad mencoder/mplayer version. I've seen it before mencoder not willing to hardcode/dump subtitles
If you call current svn (always current for me) "bad version" lol.
But as said before, mencoder cannot handle B-frames in mp4 (nor any other lavf-container). This can be worked around using elementary streams and then mux using gpac, but this can and will sooner or later screw up your a/v sync because timestamps are lost. That's why I really want to have one single program that does it all in one pass. I am here to spread the heresy that, in my opinion based on the evidence of my eyes alone, b-frames only help compression, not quality, so not having them is no big loss if you are after a quality encode. I wouldn't hang my hat on ffmpeg's output based on the fact that it can output b-frames to an .mp4 stream. The advantages of Mencoder far outweigh this one small disadvantage.
Hi. Le quintidi 5 germinal, an CCXVI, James Hastings-Trew a écrit :
I am here to spread the heresy that, in my opinion based on the evidence of my eyes alone, b-frames only help compression, not quality
I am not sure what you mean here. Video compression is a matter of balance between quality and compression: compress more, you get poorer quality; aim for better quality, you get bigger files. To say that something helps for compression must mean that that something allow to get smaller files with the same quality. Therefore, the very same something helps for quality: just aim for a slightly better quality than the original. Regards, -- Nicolas George
James Hastings-Trew wrote:
I am here to spread the heresy that, in my opinion based on the evidence of my eyes alone, b-frames only help compression, not quality, so not having them is no big loss if you are after a quality encode. I wouldn't hang my hat on ffmpeg's output based on the fact that it can output b-frames to an .mp4 stream. The advantages of Mencoder far outweigh this one small disadvantage.
Did you also try b-pyramid and more reference frames? B-frames are a bit more useful in h264 than they were before. Also, of course you are right, you don't need B-frames for quality. You don't even need P-frames. Even more, you don't need compression at all for that >:-) And yeah, I'd like to have my material compressed somewhat, I now get commercial DVD's down to ~2.3 Gb without visible quality loss at all.
Erik Slagter wrote:
James Hastings-Trew wrote:
Did you also try b-pyramid and more reference frames? B-frames are a bit more useful in h264 than they were before.
Also, of course you are right, you don't need B-frames for quality. You don't even need P-frames. Even more, you don't need compression at all for that >:-)
And yeah, I'd like to have my material compressed somewhat, I now get commercial DVD's down to ~2.3 Gb without visible quality loss at all. I do too, but I don't use b-frames.
Erik Slagter wrote:
Grozdan Nikolov (openSUSE Linux) wrote:
and you say mencoder can't do that, right? it can't hardcode subtitles? well, everytime i run h264enc, it proves you wrong about this... if you don't specify the -vobsubout option of mencoder, by default mencoder will hardcode the subtitles... period, been there, done that, seen it all... over
I'm saying that mencoder cannot hardcode subtitles coming from a DVD (mpeg program stream) while transcoding without the use of several steps involving temporary files holding the subtitles. Mplayer can actually do this, but it cannot transcode at the same time, which annoys me.
dvd -> mencoder -> mp4, in one pass, I think that's impossible. My approach (though not the beauty itself) does it all in one pass.
If I have some spare time the next days I will have another go at mencoder, if only to remember what exactly was the problem with mencoder and subtitling. Mencoder can in fact burn in DVD subtitles.
Try these command line options: subopts=-sid $subtitleID -spuaa 4 -spugauss 0.5 or subopts=-sid $subtitleID -spuaa 4 -spugauss 0.5 -forcedsubsonly Depending on your needs. The subtitle ID has to match the numerical subtitle ID on the DVD. Look up the other options in the manual to see what they do.
James Hastings-Trew wrote:
If I have some spare time the next days I will have another go at mencoder, if only to remember what exactly was the problem with mencoder and subtitling. Mencoder can in fact burn in DVD subtitles.
Try these command line options: subopts=-sid $subtitleID -spuaa 4 -spugauss 0.5 or subopts=-sid $subtitleID -spuaa 4 -spugauss 0.5 -forcedsubsonly
As said, I will try to (re) find out what the problem was shortly.
James Hastings-Trew wrote:
Erik Slagter wrote:
If I have some spare time the next days I will have another go at mencoder, if only to remember what exactly was the problem with mencoder and subtitling. Mencoder can in fact burn in DVD subtitles.
BTW I have indeed tried this again, and now I remember the problem. Mencoder can only output reliably to avi (not even separate raw video and audio stream, simultaniously...) while mp4box (gpac) cannot handle h264 in avi, so...
Erik Slagter wrote:
James Hastings-Trew wrote:
Erik Slagter wrote:
If I have some spare time the next days I will have another go at mencoder, if only to remember what exactly was the problem with mencoder and subtitling. Mencoder can in fact burn in DVD subtitles.
BTW I have indeed tried this again, and now I remember the problem.
Mencoder can only output reliably to avi (not even separate raw video and audio stream, simultaniously...) while mp4box (gpac) cannot handle h264 in avi, so... Nonsense. I use mencoder to encode to mp4 containers all the time, and without AV synch issues. I just don't use b-frames.
Having said that, I am coming around to the idea that h.264 is not the be-all and end-all of video encoding that some people think it is. I've been using mpeg4 for HD encodes (720p) because the artifacts are not as annoying as those from h.264. To my eyes, mpeg4 seems "truer" to the original source. I use h264 for those applications and devices that require it (ipod/iphone).
On Sun, Apr 06, 2008 at 10:09:50AM -0500, James Hastings-Trew wrote:
Erik Slagter wrote:
James Hastings-Trew wrote:
Erik Slagter wrote:
[snip]
Having said that, I am coming around to the idea that h.264 is not the be-all and end-all of video encoding that some people think it is. I've been using mpeg4 for HD encodes (720p) because the artifacts are not as annoying as those from h.264. To my eyes, mpeg4 seems "truer" to the
interesting I have come to the same conclusion after spending a few weeks encoding family video, in multiple bitrate and some various other options on and off. I must say though I am no expert of the options switchs available and have relied upon the mailing list and the web site to try and get the best encoding options
original source. I use h264 for those applications and devices that require it (ipod/iphone).
_______________________________________________ MEncoder-users mailing list MEncoder-users@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/mencoder-users
-- Youth is a disease from which we all recover. -- Dorothy Fuldheim
Alex Samad wrote:
I must say though I am no expert of the options switchs available and have relied upon the mailing list and the web site to try and get the best encoding options
What options are you using? I agree h264 cannot perform miracles, not even on noise-free cartoons, but I expect it to perform 15-25% better than mpeg4-2, which also actually is my experience. I assume you are aware of the "q"-parameter-range being quite different between h264 and mpeg4-2? You also enabled b-frames, b-pyramid and multiple references?
James Hastings-Trew wrote:
Mencoder can only output reliably to avi (not even separate raw video and audio stream, simultaniously...) while mp4box (gpac) cannot handle h264 in avi, so...
Nonsense. I use mencoder to encode to mp4 containers all the time, and without AV synch issues. I just don't use b-frames.
That's the whole point. For any (output-)format other than avi and mpeg (program stream/transport stream?) mencoder uses lavf, which in itself handles b-frames well, but mencoder in combination with lavf doesn't. So, output to mp4 with b-frames, no way. B-frames are there for a reason... There is no industry conspiracy that makes you believe you cannot live without b-frames even though they only cost you money. Anyway, b-frames are a requirement for me and thus I cannot use mencoder to output mp4, that's all there is to it. The a/v sync issues start to come when you need to output to raw video and raw audio (because you cannot use the mp4 muxer etc.)
Having said that, I am coming around to the idea that h.264 is not the be-all and end-all of video encoding that some people think it is. I've been using mpeg4 for HD encodes (720p) because the artifacts are not as annoying as those from h.264. To my eyes, mpeg4 seems "truer" to the original source. I use h264 for those applications and devices that require it (ipod/iphone).
h264 has a few interesting practical points compared to mpeg4-2 imho: - almost always encapsulated in mp4, which has clean support for b-frames (and b-frames as references!), so far less prone for incompatibility issues in this area; - altogether far less stories on incompatibility due to certain vendors implementing their own "extensions" upon a subset of a _standard_ and then branding it as their own ("DivX"); - "mpeg4-2 is a failed experiment" (quoting Måns Rulgård here, quoting the broadcasting industry) - I expect less and less new hardware devices supporting mpeg4-2. and a few more, gut-feeling like things I won't bother you with.
Nonsense. I use mencoder to encode to mp4 containers all the time, and without AV synch issues. I just don't use b-frames.
That's the whole point. For any (output-)format other than avi and mpeg (program stream/transport stream?) mencoder uses lavf, which in itself handles b-frames well, but mencoder in combination with lavf doesn't.
So, output to mp4 with b-frames, no way.
B-frames are there for a reason... There is no industry conspiracy that makes you believe you cannot live without b-frames even though they only cost you money. Anyway, b-frames are a requirement for me and thus I cannot use mencoder to output mp4, that's all there is to it. I don't understand your reasoning here. There are devices on the market
Erik Slagter wrote: that use mp4 and can't handle b-frames at all (ipod, psp). Certainly nothing *requires* b-frames. My mp4s look fine, and are of reasonable size, without them. It's not a "no way" situation. Every other solution I have seen that involves separating the video and audio streams and remuxing into the mp4 container, all with the *only* "benefit" being that the stream can contain b-frames, results in a/v desynch, which is far more bothersome to me than the worrying thought that what I am watching doesn't have any b-frames in it. It's not essential in the way that you seem to have made it out to be. Having said that, have a look at Handbrake ( http://handbrake.fr/?article=download ). It is a ffmpeg-based product that has a command-line component that will produce proper mp4 files with b-frames, and can burn in subtitles. The downside is that you lose mencoder's wonderful filters and scaling, so the resulting image looks a bit "soft" to my eyes. But heck, it's a b-frame fest in there, and that's what matters, right?
On Sun, 06 Apr 2008 12:01:01 +0200 Erik Slagter <erik@slagter.name> wrote:
BTW I have indeed tried this again, and now I remember the problem.
Mencoder can only output reliably to avi (not even separate raw video and audio stream, simultaniously...)
Sure it can. What's "unreliable" about it?
while mp4box (gpac) cannot handle h264 in avi
mpeg4ip (mp4creator) has no such limitation.
RC wrote:
On Sun, 06 Apr 2008 12:01:01 +0200 Erik Slagter <erik@slagter.name> wrote:
BTW I have indeed tried this again, and now I remember the problem.
Mencoder can only output reliably to avi (not even separate raw video and audio stream, simultaniously...)
Sure it can. What's "unreliable" about it?
As soon as you use b-frames, output to any other muxer than avi (maybe the builtin ps/ts muxer, I am not sure about that) is broken. This is documented behaviour.
while mp4box (gpac) cannot handle h264 in avi mpeg4ip (mp4creator) has no such limitation.
That might be a valid option, although the last few times I tried mp4creator, it was segfault galore. Also IIRC it has all sorts of GUI libs dependencies even for non-gui operation. Bottom line of my statement is that mencoder should simply support b-frames correctly, this problem has been around for ages and also has been known for ages. Having said that, I won't be the one tackling this, so I guess I'll have to shut up. Furthermore, the mp4 output of lavf is not 100% sane (although close to it). But that's not mencoder's fault. I'd rather stick on the safe side and use mp4box for the muxing, these guys actually _like_ the mp4 format (whether that's good or bad) while the ffmpeg guys really don't.
On Mon, 07 Apr 2008 13:45:01 +0200 Erik Slagter <erik@slagter.name> wrote:
Sure it can. What's "unreliable" about it?
As soon as you use b-frames, output to any other muxer than avi (maybe the builtin ps/ts muxer, I am not sure about that) is broken. This is documented behaviour.
That's not "unreliable". It's perfectly consistent behavior...
mpeg4ip (mp4creator) has no such limitation.
That might be a valid option, although the last few times I tried mp4creator, it was segfault galore. Also IIRC it has all sorts of GUI libs dependencies even for non-gui operation.
mp4creator has no GUI dependencies that I've ever come across, though of course some packages of it might. And I haven't had it segfault yet.
On Mon, 24 Mar 2008 20:08:31 +0100 Erik Slagter <erik@slagter.name> wrote:
I'm saying that mencoder cannot hardcode subtitles coming from a DVD (mpeg program stream) while transcoding without the use of several steps involving temporary files holding the subtitles.
I haven't the slightest idea what could possibly make you believe that.
But as said before, mencoder cannot handle B-frames in mp4 (nor any other lavf-container). This can be worked around using elementary streams and then mux using gpac, but this can and will sooner or later screw up your a/v sync because timestamps are lost. That's why I really want to have one single program that does it all in one pass.
MP4Box doesn't need elementary streams. Seperate A/V streams doesn't inherently mean losing sync.
RC wrote:
I'm saying that mencoder cannot hardcode subtitles coming from a DVD (mpeg program stream) while transcoding without the use of several steps involving temporary files holding the subtitles.
I haven't the slightest idea what could possibly make you believe that.
Some people at the devel mailing list, like I said before. But maybe in the meantime mencoder has been enhanced with this functionality. See the other messages.
But as said before, mencoder cannot handle B-frames in mp4 (nor any other lavf-container). This can be worked around using elementary streams and then mux using gpac, but this can and will sooner or later screw up your a/v sync because timestamps are lost. That's why I really want to have one single program that does it all in one pass.
MP4Box doesn't need elementary streams.
In theory: indeed. In practice: it tends to choke on various containers. All of my transport streams make mp4box segfault and large mp4 files also tend to do unsane things to mp4box. And I'd rather not use avi files if you don't mind, especially when big.
Seperate A/V streams doesn't inherently mean losing sync.
In practice it does. For example: if you rip part of a DVD, the audio and video will be skewed (this more or less follows from the requirements on DVD's). With the timestamps, this is no problem. Without the timestamps you're screwed. Sometimes this even happens when copying a full DVD. Same goes for transport streams received by DVB, they tend to miss a video or audio frame once in a while. Without the timestamps, you're lost. Once I had a "solution" involving projectX, which indeed guarantees that you can use the elementary streams without a/v sync issues, BUT the timestamp-straightening algorithm appears to be a little bit too aggressive, so it constantly keeps dropping and duplicating frames when the timestamps are just a little bit off. This is annoying in panning scenes. Also I don't like java apps for various reasons :-/ Anyway, to cut a long story short, there doesn't seem to be the "elegant" solution to my problem I was hoping for. Maybe mencoder might help a bit, I will have a look at this. Sadly most countries audio-dub their DVD's so there is little interest in subtitling by the developers of multimedia applications.
On Tuesday 25 March 2008 18:21, Erik Slagter wrote:
RC wrote:
I'm saying that mencoder cannot hardcode subtitles coming from a DVD (mpeg program stream) while transcoding without the use of several steps involving temporary files holding the subtitles.
I haven't the slightest idea what could possibly make you believe that.
Some people at the devel mailing list, like I said before. But maybe in the meantime mencoder has been enhanced with this functionality. See the other messages.
But as said before, mencoder cannot handle B-frames in mp4 (nor any other lavf-container). This can be worked around using elementary streams and then mux using gpac, but this can and will sooner or later screw up your a/v sync because timestamps are lost. That's why I really want to have one single program that does it all in one pass.
MP4Box doesn't need elementary streams.
In theory: indeed. In practice: it tends to choke on various containers. All of my transport streams make mp4box segfault and large mp4 files also tend to do unsane things to mp4box. And I'd rather not use avi files if you don't mind, especially when big.
Seperate A/V streams doesn't inherently mean losing sync.
In practice it does. For example: if you rip part of a DVD, the audio and video will be skewed (this more or less follows from the requirements on DVD's). With the timestamps, this is no problem. Without the timestamps you're screwed. Sometimes this even happens when copying a full DVD.
Same goes for transport streams received by DVB, they tend to miss a video or audio frame once in a while. Without the timestamps, you're lost.
Once I had a "solution" involving projectX, which indeed guarantees that you can use the elementary streams without a/v sync issues, BUT the timestamp-straightening algorithm appears to be a little bit too aggressive, so it constantly keeps dropping and duplicating frames when the timestamps are just a little bit off. This is annoying in panning scenes. Also I don't like java apps for various reasons :-/
Anyway, to cut a long story short, there doesn't seem to be the "elegant" solution to my problem I was hoping for. Maybe mencoder might help a bit, I will have a look at this.
Sadly most countries audio-dub their DVD's so there is little interest in subtitling by the developers of multimedia applications.
Have you tried playing around with avidemux? -- Regards
Grozdan Nikolov (openSUSE Linux) wrote:
Sadly most countries audio-dub their DVD's so there is little interest in subtitling by the developers of multimedia applications.
Have you tried playing around with avidemux?
Doing that now ;-) Problem with avidemux is that it has a lot of functionality and a lot of bugs :-/
On Tue, 25 Mar 2008 18:21:30 +0100 Erik Slagter <erik@slagter.name> wrote:
But maybe in the meantime mencoder has been enhanced with this functionality.
Did you ask 10+ years ago? Otherwise: absolutely not.
See the other messages.
I've read them. What am I supposed to be seeing?
In practice: it tends to choke on various containers.
A moot point... You have not been asking about remuxing random files you find, directly with MP4Box.
And I'd rather not use avi files if you don't mind, especially when big.
Obviously if you'd "rather not" use the available options, the task will be much more difficult to accomplish.
Seperate A/V streams doesn't inherently mean losing sync.
In practice it does.
Still no.
For example: if you rip part of a DVD, the audio and video will be skewed
Once again, moot. You aren't asking about directly remuxing DVDs.
participants (6)
-
Alex Samad -
Erik Slagter -
Grozdan Nikolov (openSUSE Linux) -
James Hastings-Trew -
Nicolas George -
RC