[PATCH] new mpeg muxer
Hi, attached is a huge patch to replace the current mpeg muxer with one that can mux to dvd/svcd/ generic mpeg1/2 formats. Respect to the last version I posted in -users the following problems have been fixed: - generic mpeg1/2 would lead to desync after few seconds - muxes mpeg4video (but the demuxer still had to be patched) - handles correctly null-frames inserted by mplayer, consequently the new muxer auto synchronizes after few seconds like the old one - handles correctly telecining/variable fps - added the options to timestamp all frames and to disable video frame reordering. - in case of mpeg1/2 handles the system header the same way as the old muxer did In the patch there are some necessary fixes in the muxer layer and to mencoder.c itself, but it's little code. For some months now I received a lot of positive feedback, and now that synchronization works well there's nothing in the old muxer that we may miss. If no one object I will commit saturday 19th (a week should be enough for reviewing the patch). Nico
On Sat, Feb 12, 2005 at 08:05:06PM +0100, Nico Sabbi wrote:
Hi, attached is a huge patch to replace the current mpeg muxer with one that can mux to dvd/svcd/ generic mpeg1/2 formats. Respect to the last version I posted in -users the following problems have been fixed:
excellent! exciting news!
- generic mpeg1/2 would lead to desync after few seconds - muxes mpeg4video (but the demuxer still had to be patched) - handles correctly null-frames inserted by mplayer, consequently the
this is good, but in practice it will break strict gop structuring. probably better to use vf_harddup unless you just don't care. rich
D Richard Felker III wrote:
- generic mpeg1/2 would lead to desync after few seconds - muxes mpeg4video (but the demuxer still had to be patched) - handles correctly null-frames inserted by mplayer, consequently the
this is good, but in practice it will break strict gop structuring. probably better to use vf_harddup unless you just don't care.
rich
it won't break anything: no null-frame is inserted, instead the pts of the next video frame will start from current_pts+frametime (a small temporal discontinuity). In any case harddup may still be used (and possibly work better). I'll update the man page with the rest of the doc.
Hi, On Sat, 12 Feb 2005 20:05:06 +0100, Nico Sabbi <nsabbi@tiscali.it> wrote:
Hi, attached is a huge patch to replace the current mpeg muxer with one that can mux to dvd/svcd/
That's maybe a dumb question, but is this big clean-up to the muxer as much work as it would be to correct long-term bugs in video-aspect and duration detection in the demuxer layer for vob files? In other words, does the muxer and the demuxer suffer form the same kind of problems? Is what I'm saying any clear? :-( Regards, Guillaume
Guillaume Poirier wrote:
Hi,
On Sat, 12 Feb 2005 20:05:06 +0100, Nico Sabbi <nsabbi@tiscali.it> wrote:
Hi, attached is a huge patch to replace the current mpeg muxer with one that can mux to dvd/svcd/
That's maybe a dumb question, but is this big clean-up to the muxer as much work as it would be to correct long-term bugs in video-aspect and duration detection in the demuxer layer for vob files?
no; it's all work done in the muxer because if I had to clean and pass around all the informations (an incredible mess) that telecining implies I would have to break the work done in video.c (that is somewhat working, at least mostly, but I don't understand how), fill more stuff in sh_video and especially create more infrastructure to pass these data from mencoder to the various muxers. Nico
On Sat, Feb 12, 2005 at 08:05:06PM +0100, Nico Sabbi wrote:
Hi, attached is a huge patch to replace the current mpeg muxer with one that can mux to dvd/svcd/ generic mpeg1/2 formats. [snip] If no one object I will commit saturday 19th (a week should be enough for reviewing the patch).
Still not committed - is anything wrong?
Hi, Nico Sabbi! Sometime (on Monday, February 21 at 10:43) I've received something...
I'm waiting Andrej's approval, that friday complained of a couple issues that are now fixed in my local tree.
No more objections. You did a great work, thank you. Commit it and let's all test it thoroughly. :) With best wishes. Andriy.
On Mon, Feb 21, 2005 at 09:43:14AM +0100, Nico Sabbi wrote:
Jeff wrote:
If no one object I will commit saturday 19th (a week should be enough for reviewing the patch).
Still not committed - is anything wrong?
I'm waiting Andrej's approval, that friday complained of a couple issues that are now fixed in my local tree.
Nico
What about the man page? It seems to me that the patch doesn't add anything to the documentation, isn't it? Giacomo
Giacomo Comes wrote:
What about the man page? It seems to me that the patch doesn't add anything to the documentation, isn't it?
Giacomo
I will write and commit it tonight, with the rest of the code
Nico Sabbi wrote:
Hi, attached is a huge patch to replace the current mpeg muxer with one that can mux to dvd/svcd/ generic mpeg1/2 formats.
[snip]
If no one object I will commit saturday 19th (a week should be enough for reviewing the patch).
Nico
committed with the following changes: - packs are written only when totally full: reduces overhead and makes xvcd finally work; typical overhead seems to be < 2% for dvd, <1.7% for [s]vcd, < 1.2% for generic mpeg - initial system header updated at the second call of muxer_write_header, as did the original mpeg muxer - removed all changes in mencoder.c and the new_osh* in muxer.c Man patch to follow later
On Mon, Feb 21, 2005 at 10:50:13PM +0100, Nico Sabbi wrote:
Nico Sabbi wrote:
Hi, attached is a huge patch to replace the current mpeg muxer with one that can mux to dvd/svcd/ generic mpeg1/2 formats.
[snip]
If no one object I will commit saturday 19th (a week should be enough for reviewing the patch).
Nico
committed with the following changes: - packs are written only when totally full: reduces overhead and makes xvcd finally work; typical overhead seems to be < 2% for dvd, <1.7% for [s]vcd, < 1.2% for generic mpeg - initial system header updated at the second call of muxer_write_header, as did the original mpeg muxer - removed all changes in mencoder.c and the new_osh* in muxer.c
Man patch to follow later
excellent! so this actually makes playable vcd/svcd/dvd mpeg tracks, with only mencoder and no other tools? i hate vcd because it's horrible quality and a waste of space, but it could be very convenient still! rich
D Richard Felker III wrote:
committed with the following changes: - packs are written only when totally full: reduces overhead and makes xvcd finally work; typical overhead seems to be < 2% for dvd, <1.7% for [s]vcd, < 1.2% for generic mpeg - initial system header updated at the second call of muxer_write_header, as did the original mpeg muxer - removed all changes in mencoder.c and the new_osh* in muxer.c
Man patch to follow later
excellent! so this actually makes playable vcd/svcd/dvd mpeg tracks, with only mencoder and no other tools? i hate vcd because it's horrible quality and a waste of space, but it could be very convenient still!
rich
yes, but obviously you still need to use dvdauthor and vcdimager to create image discs. Modern (especially cheap) dvd players can also play [s]vcd discs that contain non-standard mpeg1/2: mine plays perfectly vcds with 720x576 mpeg2 and 48 khz ac3 straight out of dvb, so there's still something to gain out of these old formats, especially if one doesn't have a dvd writer. Nico
On Mon, Feb 21, 2005 at 11:03:40PM +0100, Nico Sabbi wrote:
excellent! so this actually makes playable vcd/svcd/dvd mpeg tracks, with only mencoder and no other tools? i hate vcd because it's horrible quality and a waste of space, but it could be very convenient still!
rich
yes, but obviously you still need to use dvdauthor and vcdimager to create image discs. Modern (especially cheap) dvd players can also play [s]vcd discs that contain non-standard mpeg1/2: mine plays perfectly vcds with 720x576 mpeg2 and 48 khz ac3 straight out of dvb, so there's still something to gain out of these old formats, especially if one doesn't have a dvd writer.
Nico
ok, at some point someone should make a guide for how to encode (compliant) vcd/svcd/dvd with mencoder's new mpeg muxer. a few questions i have right away: - is there any way to make the muxer handle soft telecine for you (tff/rff flags)? i know vcd allows 24fps, but dvd and maybe svcd require fake 30fps with stupid flags. - lavc encodes keyframes (or perhaps the first p frame after a key frame?) at very high quantizer trying to maintain cbr, resulting in an ugly low-frequency flicker once every gop. is there a workaround? - what encoder options do you use to make compliant mpeg1/2 video for vcd/svcd/dvd? so far i've had luck, but the players i've tested might just be forgiving.. - i seem to occasionally get weird out-of-order glitched frames during really high motion scenes. is this due to buggy reordering of some sort in the muxer, failure to enforce closed gops, or something else? i think i can extract small samples that exhibit the problem if you want to see one. anyway, great job! it's amazing that this is finally (mostly) working. rich
On Wed, Feb 23, 2005 at 06:27:49PM -0500, D Richard Felker III wrote:
- i seem to occasionally get weird out-of-order glitched frames during really high motion scenes. is this due to buggy reordering of some sort in the muxer, failure to enforce closed gops, or something else? i think i can extract small samples that exhibit the problem if you want to see one.
fyi, the "noreorder" option makes the problem go away, but i have no idea if the resulting file is "valid". i'm very confused what reordering would be needed for anyway, since the encoder always outputs frames in decoding order, not display order. with that said, i expect the bug is occurring when lavc's scene change detection kicks in and causes a new gop to start somewhere it shouldn't. i'm going to try disabling scene change detection and reenabling reordering and see if that fixes the problem too. but i'm still confused why any reordering at the muxer stage would be needed or desirable. rich
D Richard Felker III wrote:
On Wed, Feb 23, 2005 at 06:27:49PM -0500, D Richard Felker III wrote:
- i seem to occasionally get weird out-of-order glitched frames during really high motion scenes. is this due to buggy reordering of some sort in the muxer, failure to enforce closed gops, or something else? i think i can extract small samples that exhibit the problem if you want to see one.
fyi, the "noreorder" option makes the problem go away, but i have no idea if the resulting file is "valid". i'm very confused what reordering would be needed for anyway, since the encoder always outputs frames in decoding order, not display order.
with that said, i expect the bug is occurring when lavc's scene change detection kicks in and causes a new gop to start somewhere it shouldn't. i'm going to try disabling scene change detection and reenabling reordering and see if that fixes the problem too. but i'm still confused why any reordering at the muxer stage would be needed or desirable.
rich
disabling reordering makes sense, but as I wrote in the other reply very early versions of some encoders (maybe even lavc older than 2 years) output frames in decoding order, so if you want to remux those streams correctly you have to reorder frames. I'm interested to see those samples and fix the bug. Maybe we should disable frame reordering by default?
Nico Sabbi wrote:
disabling reordering makes sense, but as I wrote in the other reply very early versions of some encoders (maybe even lavc older than 2 years) output frames in decoding order, so if you want to
sorry I meant in "display order", that is the wrong one
On Thu, Feb 24, 2005 at 01:06:04AM +0100, Nico Sabbi wrote:
disabling reordering makes sense, but as I wrote in the other reply very early versions of some encoders (maybe even lavc older than 2 years) output frames in decoding order, so if you want to remux those streams correctly you have to reorder frames. I'm interested to see those samples and fix the bug. Maybe we should disable frame reordering by default?
yes, it should definitely be disabled by default if it's only used for remuxing broken streams...especially since it misbehaves in the case of scene change detection in lavc. rich
D Richard Felker III wrote:
Maybe we should disable frame reordering by default?
yes, it should definitely be disabled by default if it's only used for remuxing broken streams...especially since it misbehaves in the case of scene change detection in lavc.
rich
done. Changed :noreorder to :reorder
On Wed, 23 Feb 2005, D Richard Felker III wrote:
ok, at some point someone should make a guide for how to encode (compliant) vcd/svcd/dvd with mencoder's new mpeg muxer. a few questions i have right away:
- is there any way to make the muxer handle soft telecine for you
- what encoder options do you use to make compliant mpeg1/2 video for vcd/svcd/dvd? so far i've had luck, but the players i've tested
I tried to use mencoder and lavc to create (X)SVCDs that I could play on my DVD player. I normally use mpeg2enc from the mjpegtools package, which works, but lavc is faster. I used the mplex program from mjegtools to work around mencoder's broken mpeg muxer. There were still two problems that kept it from working. The first is that I couldn't figure out a way to get soft-telecin, and trying to encode 24fps on NTSC without soft-telecin is pointless. The second is that the rate control, specifically vrc_maxrate, doesn't appear to work. No matter what rate control options I used, the encoding would have peak bitrates much too high for my DVD player to play from CD-RW media.
On Wed, Feb 23, 2005 at 03:55:11PM -0800, Trent Piepho wrote:
On Wed, 23 Feb 2005, D Richard Felker III wrote:
ok, at some point someone should make a guide for how to encode (compliant) vcd/svcd/dvd with mencoder's new mpeg muxer. a few questions i have right away:
- is there any way to make the muxer handle soft telecine for you
- what encoder options do you use to make compliant mpeg1/2 video for vcd/svcd/dvd? so far i've had luck, but the players i've tested
I tried to use mencoder and lavc to create (X)SVCDs that I could play on my DVD player. I normally use mpeg2enc from the mjpegtools package, which works, but lavc is faster. I used the mplex program from mjegtools to work around mencoder's broken mpeg muxer. There were still two problems that kept it from working.
well, the mpeg muxer is no longer broken -- that's the point.
The first is that I couldn't figure out a way to get soft-telecin, and trying to encode 24fps on NTSC without soft-telecin is pointless.
for vcd it's fine to just use 23.976 fps mode. i know this isn't allowed on dvd (very stupid!!!) but i'm not sure about svcd..? if this is an issue, it seems like it should be easy to fix. either add a hack in the mpeg muxer to do the telecine flags, or a hack in ve_lavc to add them there...
The second is that the rate control, specifically vrc_maxrate, doesn't appear to work. No matter what rate control options I used, the encoding would have peak bitrates much too high for my DVD player to play from CD-RW media.
it works as long as you set the vbv buffer size (vrc_buf_size) correctly. at least it worked for me making a vcd yesterday... rich
On Wed, 23 Feb 2005, D Richard Felker III wrote:
The second is that the rate control, specifically vrc_maxrate, doesn't appear to work. No matter what rate control options I used, the encoding would have peak bitrates much too high for my DVD player to play from CD-RW media.
it works as long as you set the vbv buffer size (vrc_buf_size) correctly. at least it worked for me making a vcd yesterday...
I did this, still didn't work. VCDs are CBR, while a SVCD is VBR, that could make a difference. I could play back the SVCDs I made with mplayer, but my DVD player couldn't handle the higher than specified bitrates and would skip.
D Richard Felker III wrote:
ok, at some point someone should make a guide for how to encode (compliant) vcd/svcd/dvd with mencoder's new mpeg muxer. a few questions i have right away:
... keeping in mind that the muxer generates totally variable muxrate and as a consequence warps the SCR, this is the reason why I called the formats xvcd and xsvcd (and as you can guess there's no cbr padding whatsoever in the stream)
- is there any way to make the muxer handle soft telecine for you (tff/rff flags)? i know vcd allows 24fps, but dvd and maybe svcd require fake 30fps with stupid flags.
at the moment the muxer detects for every video frame the tff/repeat_first_field and changes the related frame duration accordingly, so respect to the nominal fps in the seq_header a frame can last x1, x1.5, x2, x3. Afaik (but I may be wrong) other software such as pulldown.exe permit to set these fields in a progressive video, so as to emulate a telecined pattern. Is this what you mean/need?
- lavc encodes keyframes (or perhaps the first p frame after a key frame?) at very high quantizer trying to maintain cbr, resulting in an ugly low-frequency flicker once every gop. is there a workaround?
not yet, and the other muxer I tried (dvb-mplex) didn't cope with it any better, so I don't have code to steal yet :)
- what encoder options do you use to make compliant mpeg1/2 video for vcd/svcd/dvd? so far i've had luck, but the players i've tested might just be forgiving..
using short gops is the most effective solution: keyint=small N (I usually use 25, but many times I sucessfully muxed videos with N=125 without pts underruns, dts can be zeroed in that case). The problems that can appear are two: 1) pts underrun is by far the most dangerous one because it prevents (in a strictly compliant device) to play the associated audio/video frame 1) pts overflow (pts > scr + 1.0 seconds) 2) excessive buffering in the decoders The muxer tries to mux the streams with an interleaving pattern that should prevent both, usually 2) happens without problems, but currently there's no check to verify over/underflow; 1) and 1b) sometimes happens, but in that case the muxer compensates for them in the next gops Dvd are the easiest streams to handle because they have higher permitted top bitrates and specify vbr from the start, in addition they don't require pts in every frame; I never experienced problems muxing dvds; on the contrary vcd and svcds need pts in every frame, so I have to change slightly the SCR algorithm, to ensure at every single frame that pts don't over/underflow. Vcd requires cbr, but this doesn't happen because a) lavc has the problems we all know (cbr is not an option) b) the muxer doesn't even try to pad frames/gops to reach a cbr stream because it's silly (I even wonder what does the standard mean with cbr: inter-gop? inter-second? bah). In any case we should consider that a reader must be tolerant in order to deal with lavc...
- i seem to occasionally get weird out-of-order glitched frames during really high motion scenes. is this due to buggy reordering of some sort in the muxer, failure to enforce closed gops, or something else? i think i can extract small samples that exhibit the problem if you want to see one.
yes please, post the filenames. You can even disable reordering: -mpegopts noreorder (on this behalf: wrong ordering is a thing of the far past, but I guess there are still plenty of broken videos around). Closed gops don't work with lavc, but maybe you are remuxing something else?
anyway, great job! it's amazing that this is finally (mostly) working.
rich
I'd glad you like it :) Next steps are: a) finally find an algorithm that can't mux streams so as to lead to pts underrun b) verify buffering I have some very vague idea for a), never thought of b). Suggestions and patches are very welcome. Nico
On Thu, Feb 24, 2005 at 01:02:22AM +0100, Nico Sabbi wrote:
- is there any way to make the muxer handle soft telecine for you (tff/rff flags)? i know vcd allows 24fps, but dvd and maybe svcd require fake 30fps with stupid flags.
at the moment the muxer detects for every video frame the tff/repeat_first_field and changes the related frame duration accordingly, so respect to the nominal fps in the seq_header a frame can last x1, x1.5, x2, x3. Afaik (but I may be wrong) other software such as pulldown.exe permit to set these fields in a progressive video, so as to emulate a telecined pattern. Is this what you mean/need?
i'm not talking about remuxing but encoding. presumably you have a 24fps source, and want to make a valid svcd or dvd out of it. you can just increase the framerate to 30fps, inserting duplicate frames, but that will give horrible choppy 4:2:2:2 pulldown rather than 3:2:3:2. the "correct" way, as far as i'm concerned, is to encode at 24fps, but then modify the output stream to indicate 30fps and to add tff/repeat flags to alternating frames so as to emulate 24fps inside a 30fps stream, aka "soft telecine". i'm not sure whether this nasty hackery belongs in the encoder or in the muxer, though...
- what encoder options do you use to make compliant mpeg1/2 video for vcd/svcd/dvd? so far i've had luck, but the players i've tested might just be forgiving..
using short gops is the most effective solution: keyint=small N (I usually use 25, but many times I sucessfully muxed videos with N=125 without pts underruns, dts can be zeroed in that case).
obviously you want the compliant gop sizes... ;) i meant other stuff, like presence/absence of b frames, what the correct gop sizes are, correct bitrates and vbv buffer sizes, etc...
Vcd requires cbr, but this doesn't happen because a) lavc has the problems we all know (cbr is not an option) b) the muxer doesn't even try to pad frames/gops to reach a cbr stream because it's silly (I even wonder what does the standard mean with cbr: inter-gop? inter-second? bah).
cbr means within the window of the vbv buffer size...
In any case we should consider that a reader must be tolerant in order to deal with lavc...
are you sure? i've had good luck getting lavc to output cbr for vcd, as long as you specify the correct rate for min/max rate and the correct vbv buffer size.
- i seem to occasionally get weird out-of-order glitched frames during really high motion scenes. is this due to buggy reordering of some sort in the muxer, failure to enforce closed gops, or something else? i think i can extract small samples that exhibit the problem if you want to see one.
yes please, post the filenames.
imo it's not worthwhile. the bug can trivially be reproduced by encoding any video with enough motion to make lavc's scene-change detection kick in, in which case the reordering misorders a frame.
Closed gops don't work with lavc, but maybe you are remuxing something else?
nope. i have no interest in using other programs; it's too much work dealing with all the temp files/pipes, and too slow...
I'd glad you like it :) Next steps are: a) finally find an algorithm that can't mux streams so as to lead to pts underrun b) verify buffering
I have some very vague idea for a), never thought of b). Suggestions and patches are very welcome.
my biggest suggestion would be padding for compliance. i know it's stupid, but being able to generate 100% or even 90% compiant vcd/svcd/dvd with no tools other than mencoder would be a huge step forward over the mess of scripts and awkward tools everyone has to use now. personally i don't care about vcd enough to use it if i have to go though the pain of all that stuff, but if i can make a vcd with just mencoder, i might actually use them now and then for preparing videos for use on hardware players. rich
D Richard Felker III wrote:
the "correct" way, as far as i'm concerned, is to encode at 24fps, but then modify the output stream to indicate 30fps and to add tff/repeat flags to alternating frames so as to emulate 24fps inside a 30fps stream, aka "soft telecine". i'm not sure whether this nasty hackery belongs in the encoder or in the muxer, though...
Actually, I wish there was a way where a filter can set the rff/tff flags which could get passed down to the encoder and muxer. That would allow filterss like pullup or filmdint to output at any fps between 20000/1001 and 30000/1001. And the reason you need that is that many things on TV are rate-changed. Even for TV shows, the original is shown at 24000/1001 fps, but the repeat is sped up to make room for an extra 30sec commercial block. The the framerate changer they use sucks badly, as it just blindly drops fields from the telecined content, so you get 2-3-2-2-2-3-2 or 3-2-3-1-3-2-3 telecine, but never 2-3-2-2-3-2 which would be the smoothest. Alternatively, mencoder could set the fields automatically. Currently mencoder skip/dup frames to keep the A-V sync, but it could use the rff flag instead. It could automatically add or omit rff to keep the A/V sync, and the advantage is that it has a half-frame precision. In that case the video filters could produce any frame rate up to 30000/1001, and pullup or filmdint would just work without specifying -ofps or using -ofps 30000/1001. Btw, is there a way to use vcodec=mpeg4 with -of mpeg? That's not for DVD, just for computer playback, but using mpg instead of avi? I've tried it, but it did not work for me, but maybe I just do not know what I'm doing. Zoli
Zoltan Hidvegi wrote:
Btw, is there a way to use vcodec=mpeg4 with -of mpeg? That's not for DVD, just for computer playback, but using mpg instead of avi? I've tried it, but it did not work for me, but maybe I just do not know what I'm doing.
Zoli
yes, it already works, but you need tcvp or a checkout of vlc to play it. I'll patch mplayer' demuxer ASAP
Hi On Thursday 24 February 2005 01:56, D Richard Felker III wrote: [...]
I'd glad you like it :) Next steps are: a) finally find an algorithm that can't mux streams so as to lead to pts underrun b) verify buffering
I have some very vague idea for a), never thought of b). Suggestions and patches are very welcome.
my biggest suggestion would be padding for compliance. i know it's stupid, but being able to generate 100% or even 90% compiant vcd/svcd/dvd with no tools other than mencoder would be a huge step forward over the mess of scripts and awkward tools everyone has to use now. personally i don't care about vcd enough to use it if i have to
maybe fixing lavf muxing support would be the best idea then, its supposed to be a 100% compliant (s)vcd muxer but it seems some people prefer to rewrite everything, thats fine too, just a little sad, as the time could have been spent fixing/improving the existing code in libavformat from which many projects and not just mencoder would have benefited anyway, small question, does the new mpeg muxer support anything lavf doesnt? iam just asking so i know what to put on my todo list [...] -- Michael "nothing is evil in the beginning. Even Sauron was not so." -- Elrond
On Thu, Feb 24, 2005 at 02:22:52PM +0100, Michael Niedermayer wrote:
Hi
On Thursday 24 February 2005 01:56, D Richard Felker III wrote: [...]
I'd glad you like it :) Next steps are: a) finally find an algorithm that can't mux streams so as to lead to pts underrun b) verify buffering
I have some very vague idea for a), never thought of b). Suggestions and patches are very welcome.
my biggest suggestion would be padding for compliance. i know it's stupid, but being able to generate 100% or even 90% compiant vcd/svcd/dvd with no tools other than mencoder would be a huge step forward over the mess of scripts and awkward tools everyone has to use now. personally i don't care about vcd enough to use it if i have to
maybe fixing lavf muxing support would be the best idea then, its supposed to be a 100% compliant (s)vcd muxer
but it seems some people prefer to rewrite everything, thats fine too, just a little sad, as the time could have been spent fixing/improving the existing code in libavformat from which many projects and not just mencoder would have benefited
anyway, small question, does the new mpeg muxer support anything lavf doesnt? iam just asking so i know what to put on my todo list
all i know is that i was never able to get a working vcd out of ffmpeg. granted it was a few months ago that i tried, so maybe it works now. as for lavf support, imo the biggest thing in mencoder's new mpeg muxer is dealing with and fixing timestamps, since they don't exist to begin with and mencoder makes it extremely hard to make up valid ones. with an mpeg-specific muxer at least you know the few codecs you're dealing with, so you can parse the codec's frames to help you. i suppose the same could be done with a lavf muxer if we cared to parse lots of different codecs, but it would be a pain. :( actually last night i had this idea that we should add pts to mplayer g1's decoder/filter layer soon, and just not use it to begin with. then after playing around with it for a while and getting it working, we could gradually replace the mencoder a/v sync code with something non-idiotic, and of course have working lavf muxer too! rich
D Richard Felker III wrote:
actually last night i had this idea that we should add pts to mplayer g1's decoder/filter layer soon, and just not use it to begin with.
I agree: imo mencoder's core that should calculate pts, not the muxer.
then after playing around with it for a while and getting it working, we could gradually replace the mencoder a/v sync code with something non-idiotic, and of course have working lavf muxer too!
rich
On this behalf: I need a way to know the audio frame size to get accurate pts for muxer_lavf
Sorry for this hand-made reply, but I lost the original message. D Richard Felker III wrote:
i'm not talking about remuxing but encoding. presumably you have a 24fps source, and want to make a valid svcd or dvd out of it. you can just increase the framerate to 30fps, inserting duplicate frames, but that will give horrible choppy 4:2:2:2 pulldown rather than 3:2:3:2.
the "correct" way, as far as i'm concerned, is to encode at 24fps, but then modify the output stream to indicate 30fps and to add tff/repeat flags to alternating frames so as to emulate 24fps inside a 30fps stream, aka "soft telecine". i'm not sure whether this nasty hackery belongs in the encoder or in the muxer, though... rich
ok, now I understand. Seems reasonably easy to do. I'll work at it this weekend
obviously you want the compliant gop sizes... ;)
not necessarily, especially considering that for vcd the standard requires 12 for pal
i meant other stuff, like presence/absence of b frames, what the correct gop sizes are, correct bitrates and vbv buffer sizes, etc...
so, as far as I know (my knowledge is limited to what can be read online, because I don't have even a draft of the standard) these are the official encoding parameters: for all: max gop length: 15 for pal, 18 for ntsc, 2 max b-frames vcd: vbv 46 KB, bitrate 1150 kb/s cbr svcd:vbv 92 KB, bitrate: audio+video must not exceed ~2700 kb/s sustained dvd: vbv 230 KB, bitrate audio+video must not exceed ~9800 kb/s sustained My experiences: using 25 frames gops in my pal encodes always worked correctly for all 3 formats; trying to enforce vbv constraints often lead to buffer underrun in the lavc, that lead to problems in the muxer (pts underrun). Trying to limit the max bitrate often doesn't work (tops also at 13 Mb/s). I understand that vbv and maxrate are bound, so maybe I didn't use them correctly. Tonight I will disable frame reordering by default, and try to fix what causes the flashing when scene change kicks in. What value did you use for sc_threshold? Nico
On Thu, Feb 24, 2005 at 04:01:13PM +0100, Nico Sabbi wrote:
Tonight I will disable frame reordering by default, and try to fix what causes the flashing when scene change kicks in. What value did you use for sc_threshold?
before i was using whatever the default is, but i changed it to 1000000 to disable scene change detection. actually it needs to be disabled for compliant gop structure, i think...but still the muxer shouldn't misorder frames. rich
D Richard Felker III wrote:
On Thu, Feb 24, 2005 at 04:01:13PM +0100, Nico Sabbi wrote:
Tonight I will disable frame reordering by default, and try to fix what causes the flashing when scene change kicks in. What value did you use for sc_threshold?
before i was using whatever the default is, but i changed it to 1000000 to disable scene change detection. actually it needs to be disabled for compliant gop structure, i think...but still the muxer shouldn't misorder frames.
rich
this really puzzles me, I have never seen the muxer misordering the frames, and I believe the code is correct. Do you see the same effect if you play the dumped video?
On Thu, Feb 24, 2005 at 05:22:42PM +0100, Nico Sabbi wrote:
D Richard Felker III wrote:
On Thu, Feb 24, 2005 at 04:01:13PM +0100, Nico Sabbi wrote:
Tonight I will disable frame reordering by default, and try to fix what causes the flashing when scene change kicks in. What value did you use for sc_threshold?
before i was using whatever the default is, but i changed it to 1000000 to disable scene change detection. actually it needs to be disabled for compliant gop structure, i think...but still the muxer shouldn't misorder frames.
rich
this really puzzles me, I have never seen the muxer misordering the frames, and I believe the code is correct. Do you see the same effect if you play the dumped video?
huh? what do you mean by play the dumped video? what i'm doing is encoding to mpeg with a single run of mencoder, using lavc's mpeg1video codec with b frames. i definitely see the frames get decoded wrong (a b-frame comes out looking like complete nonsense) at points where lavc is inserting a new i-frame for scene change when i play the resulting file with mplayer. on the hardware vcd player i don't recall seeing any such glitches, probably because it throws away the frame because the way it's ordered makes no sense... rich
D Richard Felker III wrote:
huh? what do you mean by play the dumped video? what i'm doing is
I mean $ mplayer -dumpvideo -dumpfile video.m1v file.mpg $ mplayer video.m1v
encoding to mpeg with a single run of mencoder, using lavc's mpeg1video codec with b frames. i definitely see the frames get decoded wrong (a b-frame comes out looking like complete nonsense) at points where lavc is inserting a new i-frame for scene change when i play the resulting file with mplayer. on the hardware vcd player i don't recall seeing any such glitches, probably because it throws away the frame because the way it's ordered makes no sense...
rich
Michael Niedermayer wrote:
maybe fixing lavf muxing support would be the best idea then, its supposed to be a 100% compliant (s)vcd muxer
but it seems some people prefer to rewrite everything, thats fine too, just a little sad, as the time could have been spent fixing/improving the existing code in libavformat from which many projects and not just mencoder would have benefited
anyway, small question, does the new mpeg muxer support anything lavf doesnt? iam just asking so i know what to put on my todo list
I began to write the muxer in june or july last year, when lavf wan't even an option for making *vds (didn't have nav packs). Besides, it would have been a 3 steps process: getting to know lavf api, patching it and then linking it with a bridged muxer in mencoder, so I decided that it was much easier and quick to patch mencoder's muxer, although I ended up almost rewriting it. Now I agree that lavf works well too, but I don't know it, so I can't compare it with mine. There are very marginal/unimportant things that mine does (muxing mpeg4 and soon h264) and lavf doesn't, or the opposite: I don't manage lpcm. They can surely benefit from each other. Nico
Hi On Thursday 24 February 2005 15:23, Nico Sabbi wrote:
Michael Niedermayer wrote:
maybe fixing lavf muxing support would be the best idea then, its supposed to be a 100% compliant (s)vcd muxer
but it seems some people prefer to rewrite everything, thats fine too, just a little sad, as the time could have been spent fixing/improving the existing code in libavformat from which many projects and not just mencoder would have benefited
anyway, small question, does the new mpeg muxer support anything lavf doesnt? iam just asking so i know what to put on my todo list
I began to write the muxer in june or july last year, when lavf wan't even an option for making *vds (didn't have nav packs). Besides, it would have been a 3 steps process: getting to know lavf api, patching it and then linking it with a bridged muxer in mencoder, so I decided that it was much easier and quick to patch mencoder's muxer, although I ended up almost rewriting it.
never mind, sorry if my last message sounded unfriendly, it wasnt supposed to ... [...] -- Michael "nothing is evil in the beginning. Even Sauron was not so." -- Elrond
Michael Niedermayer wrote:
Hi
I began to write the muxer in june or july last year, when lavf wan't even an option for making *vds (didn't have nav packs). Besides, it would have been a 3 steps process: getting to know lavf api, patching it and then linking it with a bridged muxer in mencoder, so I decided that it was much easier and quick to patch mencoder's muxer, although I ended up almost rewriting it.
never mind, sorry if my last message sounded unfriendly, it wasnt supposed to ...
[...]
it didn't sound unfriendly.
D Richard Felker III wrote:
the "correct" way, as far as i'm concerned, is to encode at 24fps, but then modify the output stream to indicate 30fps and to add tff/repeat flags to alternating frames so as to emulate 24fps inside a 30fps stream, aka "soft telecine". i'm not sure whether this nasty hackery belongs in the encoder or in the muxer, though...
if I understand correctly I should 1) patch the fps to 29.97 or 30 2) always disable progressive sequence (lavc always sets it) 3) leave progressive frame as is 4) every frame must have either TFF or RFF, so when they are not set I should alternate them every two frames? and what when TFF is always set? Can someone confirm or correct? A link to a complete explanation would help a lot, thanks. Nico
On Fri, Feb 25, 2005 at 01:09:33AM +0100, Nico Sabbi wrote:
D Richard Felker III wrote:
the "correct" way, as far as i'm concerned, is to encode at 24fps, but then modify the output stream to indicate 30fps and to add tff/repeat flags to alternating frames so as to emulate 24fps inside a 30fps stream, aka "soft telecine". i'm not sure whether this nasty hackery belongs in the encoder or in the muxer, though...
if I understand correctly I should 1) patch the fps to 29.97 or 30 2) always disable progressive sequence (lavc always sets it) 3) leave progressive frame as is 4) every frame must have either TFF or RFF, so when they are not set I should alternate them every two frames? and what when TFF is always set?
Can someone confirm or correct? A link to a complete explanation would help a lot, thanks.
i'll explain. first of all, this should all be an option that has to be explicitly enabled. now the scenario is you're getting in video at 23.976 or 24 fps. i'm not sure of the difference between progressive sequence versus progressive frame flags. presumably all of these are set to true by the encoder. input frames should all have the same field parity set, either tff=1 or tff=0, not alternating. rff should always be 0. if any of the above conditions on the input stream fail to hold (i.e. you don't really have progressive video suitable for telecine) it's probably good to bail out with an error or at least print nasty warnings. now what to do: replace the fps by 29.97 or 30, respectively. alternatively set rff=1 on every second frame. keep a running value for tff flag, initializing it with 1 (or the value from the first input frame) and alternate it after each time you use rff=1, always storing your tff flag in place of the one in the source video. so the final rff and tff flag pattern should come out looking like: rff 0101010101010101 tff 1100110011001100 (note: you can just keep a counter "mod 4" and use bit-0 as rff, bit-1 as tff.. :) i don't know what to do with the progressive sequence/frame flags. billy biggs (vektor on freenode; sometimes he posts to this list) has done quite a bit of research on this subject and can probably tell you the correct values, as well as all the incorrect ones used on countless badly mastered dvds out there... :) rich
D Richard Felker III wrote:
now the scenario is you're getting in video at 23.976 or 24 fps.
But even better if you can handle anything between 20 and 30 (/1.001).
alternatively set rff=1 on every second frame.
Or occasionally have two consecutive frames without rff if >24fps or have two consecutive frames with rff if fps<23.976 (the later is rare, but sometimes they show a short movie in a 2 hour window on TV, they slow it down to fill the time). And of course, every time you see rff, toggle the tff in the next frame. Zoli
D Richard Felker III wrote:
i'll explain. first of all, this should all be an option that has to be explicitly enabled.
now the scenario is you're getting in video at 23.976 or 24 fps. i'm not sure of the difference between progressive sequence versus progressive frame flags. presumably all of these are set to true by the encoder. input frames should all have the same field parity set, either tff=1 or tff=0, not alternating. rff should always be 0.
if any of the above conditions on the input stream fail to hold (i.e. you don't really have progressive video suitable for telecine) it's probably good to bail out with an error or at least print nasty warnings.
now what to do:
replace the fps by 29.97 or 30, respectively. alternatively set rff=1 on every second frame. keep a running value for tff flag, initializing it with 1 (or the value from the first input frame) and alternate it after each time you use rff=1, always storing your tff flag in place of the one in the source video.
so the final rff and tff flag pattern should come out looking like: rff 0101010101010101 tff 1100110011001100 (note: you can just keep a counter "mod 4" and use bit-0 as rff, bit-1 as tff.. :)
it's a clear explanation,thank you
i don't know what to do with the progressive sequence/frame flags. billy biggs (vektor on freenode; sometimes he posts to this list) has done quite a bit of research on this subject and can probably tell you the correct values, as well as all the incorrect ones used on countless badly mastered dvds out there... :)
rich
reading the specs it seems that when both progressive fields are set the output consists of double the fields (so even 2 or 3 frames). I'll ask Billy
D Richard Felker III wrote:
i'll explain. first of all, this should all be an option that has to be explicitly enabled.
now the scenario is you're getting in video at 23.976 or 24 fps. i'm not sure of the difference between progressive sequence versus progressive frame flags. presumably all of these are set to true by the encoder. input frames should all have the same field parity set, either tff=1 or tff=0, not alternating. rff should always be 0.
if any of the above conditions on the input stream fail to hold (i.e. you don't really have progressive video suitable for telecine) it's probably good to bail out with an error or at least print nasty warnings.
now what to do:
replace the fps by 29.97 or 30, respectively. alternatively set rff=1 on every second frame. keep a running value for tff flag, initializing it with 1 (or the value from the first input frame) and alternate it after each time you use rff=1, always storing your tff flag in place of the one in the source video.
so the final rff and tff flag pattern should come out looking like: rff 0101010101010101 tff 1100110011001100 (note: you can just keep a counter "mod 4" and use bit-0 as rff, bit-1 as tff.. :)
i don't know what to do with the progressive sequence/frame flags. billy biggs (vektor on freenode; sometimes he posts to this list) has done quite a bit of research on this subject and can probably tell you the correct values, as well as all the incorrect ones used on countless badly mastered dvds out there... :)
rich
attached is a first implementation of your algorithm. :telecine sets only fps, tff and rff; :telecine2 also sets progressive sequence to 0. I asked Billy to help me but I haven't received any answer, yet. Testreports are welcome. Nico
On Sat, Feb 26, 2005 at 12:05:56PM +0100, Nico Sabbi wrote:
D Richard Felker III wrote:
i'll explain. first of all, this should all be an option that has to be explicitly enabled.
now the scenario is you're getting in video at 23.976 or 24 fps. i'm not sure of the difference between progressive sequence versus progressive frame flags. presumably all of these are set to true by the encoder. input frames should all have the same field parity set, either tff=1 or tff=0, not alternating. rff should always be 0.
if any of the above conditions on the input stream fail to hold (i.e. you don't really have progressive video suitable for telecine) it's probably good to bail out with an error or at least print nasty warnings.
now what to do:
replace the fps by 29.97 or 30, respectively. alternatively set rff=1 on every second frame. keep a running value for tff flag, initializing it with 1 (or the value from the first input frame) and alternate it after each time you use rff=1, always storing your tff flag in place of the one in the source video.
so the final rff and tff flag pattern should come out looking like: rff 0101010101010101 tff 1100110011001100 (note: you can just keep a counter "mod 4" and use bit-0 as rff, bit-1 as tff.. :)
i don't know what to do with the progressive sequence/frame flags. billy biggs (vektor on freenode; sometimes he posts to this list) has done quite a bit of research on this subject and can probably tell you the correct values, as well as all the incorrect ones used on countless badly mastered dvds out there... :)
rich
attached is a first implementation of your algorithm.
:telecine sets only fps, tff and rff; :telecine2 also sets progressive sequence to 0.
I asked Billy to help me but I haven't received any answer, yet.
Testreports are welcome.
Nico
comitted. if we find anything wrong we can fix it later, but this seems to be working fine. rich
D Richard Felker III wrote:
attached is a first implementation of your algorithm.
:telecine sets only fps, tff and rff; :telecine2 also sets progressive sequence to 0.
I asked Billy to help me but I haven't received any answer, yet.
Testreports are welcome.
Nico
comitted. if we find anything wrong we can fix it later, but this seems to be working fine.
rich
good, but which one did you use: telecine or telecine2 ? I still have two doubts. 1) at the moment telecining is applied to frames in decoding order: to me it seems natural to apply it to frames in display order, or is it wrong? 2) actually timestamps are not modified after telecining, but wouldn't the player get momentarily out of sync in the course of a second (although the user might not nitice)? Should I recalculate frame duration and pts after telecining? Thank, Nico
On Sun, Feb 27, 2005 at 09:37:24AM +0100, Nico Sabbi wrote:
D Richard Felker III wrote:
attached is a first implementation of your algorithm.
:telecine sets only fps, tff and rff; :telecine2 also sets progressive sequence to 0.
I asked Billy to help me but I haven't received any answer, yet.
Testreports are welcome.
Nico
comitted. if we find anything wrong we can fix it later, but this seems to be working fine.
rich
good, but which one did you use: telecine or telecine2 ?
I just tested the output with MPlayer, not any hardware. I don't think I have access to any hardware that's picky enough to care.. For the reference, telecine2.
I still have two doubts. 1) at the moment telecining is applied to frames in decoding order: to me it seems natural to apply it to frames in display order, or is it wrong?
Yes...this is a major problem, dammit. I've said it 1000 times it feels like, but I'll say once again: I FUCKING HATE B FRAMES!!!!!!! Whoever came up with such idiocy should be tied to heavy rocks and thrown into a huge vat of cola!!
2) actually timestamps are not modified after telecining, but wouldn't the player get momentarily out of sync in the course of a second (although the user might not nitice)? Should I recalculate frame duration and pts after telecining?
Perhaps. MPEG pts handling is really broken and I don't understand it, so I'll leave it up to you or someone else to figure it out. If you can find an easy way to do it, it probably should be done. Rich
On Feb 27, 2005, at 7:20 PM, D Richard Felker III wrote:
Yes...this is a major problem, dammit. I've said it 1000 times it feels like, but I'll say once again: I FUCKING HATE B FRAMES!!!!!!!
Whoever came up with such idiocy should be tied to heavy rocks and thrown into a huge vat of cola!!
FWIW: I like B-frames. My laptop is not really capable of full 24fps in D1 resolution, which makes playing high resolution movies with just P frames very skippy. The player has to skip long segments to the next I-frame to catch up. With interleaved B-frames the player can drop exactly the frames it can't manage to decode and playback is smoooth and audio never drifts. I don't think that's the reason B-frames were invented, but it's a nice feature. Go B-frames! :) /Roine
On Sun, Feb 27, 2005 at 11:24:39PM +0100, Roine Gustafsson wrote:
On Feb 27, 2005, at 7:20 PM, D Richard Felker III wrote:
Yes...this is a major problem, dammit. I've said it 1000 times it feels like, but I'll say once again: I FUCKING HATE B FRAMES!!!!!!!
Whoever came up with such idiocy should be tied to heavy rocks and thrown into a huge vat of cola!!
FWIW: I like B-frames. My laptop is not really capable of full 24fps in D1 resolution, which makes playing high resolution movies with just P
Are you sure? What speed is your laptop? I expect the problem is something else, like using a bad vo driver or software scaling.. Even my celeron 366 laptop can play any movie I throw at it, without -framedrop at all.
frames very skippy. The player has to skip long segments to the next I-frame to catch up. With interleaved B-frames the player can drop exactly the frames it can't manage to decode and playback is smoooth and audio never drifts.
Unless you drop a huge portion of the B frames, decoding a movie with B frames is significantly slower than decoding one without. Rich
On Feb 28, 2005, at 12:56 AM, D Richard Felker III wrote:
On Sun, Feb 27, 2005 at 11:24:39PM +0100, Roine Gustafsson wrote:
On Feb 27, 2005, at 7:20 PM, D Richard Felker III wrote:
Yes...this is a major problem, dammit. I've said it 1000 times it feels like, but I'll say once again: I FUCKING HATE B FRAMES!!!!!!!
Whoever came up with such idiocy should be tied to heavy rocks and thrown into a huge vat of cola!!
FWIW: I like B-frames. My laptop is not really capable of full 24fps in D1 resolution, which makes playing high resolution movies with just P
Are you sure? What speed is your laptop? I expect the problem is something else, like using a bad vo driver or software scaling.. Even my celeron 366 laptop can play any movie I throw at it, without -framedrop at all.
A 600Mhz G3 (PPC750CXe), ie no Altivec.
frames very skippy. The player has to skip long segments to the next I-frame to catch up. With interleaved B-frames the player can drop exactly the frames it can't manage to decode and playback is smoooth and audio never drifts.
Unless you drop a huge portion of the B frames, decoding a movie with B frames is significantly slower than decoding one without.
Well, I can only say what I'm seeing. It was just a point to say that there are positive aspects of using B-frames :) /Roine
On Feb 27, 2005, at 7:20 PM, D Richard Felker III wrote:
Yes...this is a major problem, dammit. I've said it 1000 times it feels like, but I'll say once again: I FUCKING HATE B FRAMES!!!!!!!
Whoever came up with such idiocy should be tied to heavy rocks and thrown into a huge vat of cola!!
I believe I found a simple fix to the display vs decoder order problem. I'll post the code (almost complete) soon, maybe tonight. Nico
On Feb 28, 2005, at 4:46 AM, Roine Gustafsson wrote:
A 600Mhz G3 (PPC750CXe), ie no Altivec.
It's a bug in Quartz that causes playback to be slower on OS X. It will always spend most of its CPU time in an extra (very badly written) conversion to YUV 422 and gamma correction to 1.8 inside QuickTime. There's no very good way to fix it besides waiting for 10.4 and hoping it gets better; my local copy of mplayer has its own faster replacement for the dumb Quicktime function, but the patch is too ugly to submit, and I'm not sure if improvising with -vf eq2,yuy2 would do any better.
On Mon, Feb 28, 2005 at 10:46:03AM +0100, Roine Gustafsson wrote:
On Feb 28, 2005, at 12:56 AM, D Richard Felker III wrote:
On Sun, Feb 27, 2005 at 11:24:39PM +0100, Roine Gustafsson wrote:
On Feb 27, 2005, at 7:20 PM, D Richard Felker III wrote:
Yes...this is a major problem, dammit. I've said it 1000 times it feels like, but I'll say once again: I FUCKING HATE B FRAMES!!!!!!!
Whoever came up with such idiocy should be tied to heavy rocks and thrown into a huge vat of cola!!
FWIW: I like B-frames. My laptop is not really capable of full 24fps in D1 resolution, which makes playing high resolution movies with just P
Are you sure? What speed is your laptop? I expect the problem is something else, like using a bad vo driver or software scaling.. Even my celeron 366 laptop can play any movie I throw at it, without -framedrop at all.
A 600Mhz G3 (PPC750CXe), ie no Altivec.
So much for "ppc is faster than x86 at same clock..." ;) Still, this should be fast enough. What vo are you using? You should try to get vidix working...others will be quite slow, with xv being your best alternative. x11 or any rgb-based (or non-overlay-based) vo is unusable. Rich
On Feb 28, 2005, at 4:39 PM, D Richard Felker III wrote:
On Mon, Feb 28, 2005 at 10:46:03AM +0100, Roine Gustafsson wrote:
On Feb 28, 2005, at 12:56 AM, D Richard Felker III wrote:
On Sun, Feb 27, 2005 at 11:24:39PM +0100, Roine Gustafsson wrote:
On Feb 27, 2005, at 7:20 PM, D Richard Felker III wrote:
Yes...this is a major problem, dammit. I've said it 1000 times it feels like, but I'll say once again: I FUCKING HATE B FRAMES!!!!!!!
Whoever came up with such idiocy should be tied to heavy rocks and thrown into a huge vat of cola!!
FWIW: I like B-frames. My laptop is not really capable of full 24fps in D1 resolution, which makes playing high resolution movies with just P
Are you sure? What speed is your laptop? I expect the problem is something else, like using a bad vo driver or software scaling.. Even my celeron 366 laptop can play any movie I throw at it, without -framedrop at all.
A 600Mhz G3 (PPC750CXe), ie no Altivec.
So much for "ppc is faster than x86 at same clock..." ;) Still, this should be fast enough. What vo are you using? You should try to get vidix working...others will be quite slow, with xv being your best alternative. x11 or any rgb-based (or non-overlay-based) vo is unusable.
PPC750 is somewhat like a PIII without MMX, only with a fraction of the power consumption. My laptop doesn't have a fan. (Actually, I think it has. But I've never heard it). Using Mplayer is usually OK, but I tend to prefer using Quicktime. QT has better rate control and syncs better with audio. QT needs plugins for everything tho, and has a quite broken AVI demuxer. One needs to install DivX just to use their AVI demuxer. There is now a nice vo for mplayer called quartz, which is not really using Quartz (display PDF vector compositor) but Quicktime. AFAIK noone has ported vidix to Mac. X11 on Mac is dog slow. /Roine
On Mon, Feb 28, 2005 at 05:29:02PM +0100, Roine Gustafsson wrote:
Are you sure? What speed is your laptop? I expect the problem is something else, like using a bad vo driver or software scaling.. Even my celeron 366 laptop can play any movie I throw at it, without -framedrop at all.
A 600Mhz G3 (PPC750CXe), ie no Altivec.
So much for "ppc is faster than x86 at same clock..." ;) Still, this should be fast enough. What vo are you using? You should try to get vidix working...others will be quite slow, with xv being your best alternative. x11 or any rgb-based (or non-overlay-based) vo is unusable.
PPC750 is somewhat like a PIII without MMX, only with a fraction of the power consumption. My laptop doesn't have a fan. (Actually, I think it has. But I've never heard it).
Notice that my laptop, which plays all movies fine (except hdtv of course) is a P2 celeron 366 mhz. Much slower than any P3. Granted it does have mmx, but with that much speed difference otherwise (not to mention the crappy celeron cache) things should more than balance out. IMO the problem on your system is what someone else mentioned: the buggy "QuickTime" video layer on osx converts yv12 to yuy2 behind the scenes, using very slow code, and also gamma corrects it in software which is incredibly slow and unnecessary.
Using Mplayer is usually OK, but I tend to prefer using Quicktime. QT has better rate control and syncs better with audio.
Must be due to bugs on the mac vo/ao drivers..
There is now a nice vo for mplayer called quartz, which is not really using Quartz (display PDF vector compositor) but Quicktime. AFAIK noone has ported vidix to Mac. X11 on Mac is dog slow.
Are you sure vidix isn't supported? It would be by far the best choice.. Maybe someone (I know there are plenty mac fans out there!) could port it.... Rich
Hi,
IMO the problem on your system is what someone else mentioned: the buggy "QuickTime" video layer on osx converts yv12 to yuy2 behind the scenes, using very slow code, and also gamma corrects it in software which is incredibly slow and unnecessary.
it's imho even worse. at least on my g5, it seems qt converts the yv12 image to rgb, so when doing big scaling (ie. 320x240 ->1280x1024) you can see big aliasing effect on colors, like if you first convert to to yuv 4:4:4 (or rgb) and then scale up using linear scaling... knowing, that quartz extreme (in osx 10.3.x) does every screen rendering through opengl, i can imagine it first converts yuv to rgb, and then uses the opengl renderer to scale it up...
Using Mplayer is usually OK, but I tend to prefer using Quicktime. QT has better rate control and syncs better with audio.
Must be due to bugs on the mac vo/ao drivers..
There is now a nice vo for mplayer called quartz, which is not really using Quartz (display PDF vector compositor) but Quicktime. AFAIK noone has ported vidix to Mac. X11 on Mac is dog slow.
Are you sure vidix isn't supported? It would be by far the best choice.. Maybe someone (I know there are plenty mac fans out there!) could port it....
afaik it isnt ported, and even if so, it would be hard to make it stable, as the os keeps updating the screen using full hw accel. (so there may be conflicting registers/commands on the gpu) A'rpi / MPlayer, Astral & ESP-team -- Girls are like internet domain names, the ones I like are already taken.
On Mon, Feb 28, 2005 at 08:31:44PM +0100, Arpi wrote:
Hi,
IMO the problem on your system is what someone else mentioned: the buggy "QuickTime" video layer on osx converts yv12 to yuy2 behind the scenes, using very slow code, and also gamma corrects it in software which is incredibly slow and unnecessary.
it's imho even worse. at least on my g5, it seems qt converts the yv12 image to rgb, so when doing big scaling (ie. 320x240 ->1280x1024) you can see big aliasing effect on colors, like if you first convert to to yuv 4:4:4 (or rgb) and then scale up using linear scaling...
knowing, that quartz extreme (in osx 10.3.x) does every screen rendering through opengl, i can imagine it first converts yuv to rgb, and then uses the opengl renderer to scale it up...
Using Mplayer is usually OK, but I tend to prefer using Quicktime. QT has better rate control and syncs better with audio.
Must be due to bugs on the mac vo/ao drivers..
There is now a nice vo for mplayer called quartz, which is not really using Quartz (display PDF vector compositor) but Quicktime. AFAIK noone has ported vidix to Mac. X11 on Mac is dog slow.
Are you sure vidix isn't supported? It would be by far the best choice.. Maybe someone (I know there are plenty mac fans out there!) could port it....
afaik it isnt ported, and even if so, it would be hard to make it stable, as the os keeps updating the screen using full hw accel. (so there may be conflicting registers/commands on the gpu)
Using the overlay doesn't rquire commands on the gpu, just setting a few registers. I can't see how this would conflict.. Anyway thanks for the comments. It's good to have solid facts on why OSX sucks beyond imagination. Rich
On Feb 28, 2005, at 2:31 PM, Arpi wrote:
it's imho even worse. at least on my g5, it seems qt converts the yv12 image to rgb, so when doing big scaling (ie. 320x240 ->1280x1024) you can see big aliasing effect on colors, like if you first convert to to yuv 4:4:4 (or rgb) and then scale up using linear scaling...
I don't think it's that dumb (although Windows Media Player does it); I've seen other people making workarounds who could afford g5s and they never saw anything that bad . The best way to find out is to run mplayer in Apple's Shark profiler (http://developer.apple.com/tools/performance/#CHUD); 20% time will be in YUV420To2VUY_W1x if it's the same as everything I've seen.
Hi, On Mon, Feb 28, 2005 at 08:31:44PM +0100, Arpi wrote:
knowing, that quartz extreme (in osx 10.3.x) does every screen rendering through opengl, i can imagine it first converts yuv to rgb, and then uses the opengl renderer to scale it up...
Well, their OpenGL implementation supports YUV textures... though I don't know how deep into hardware this support goes - in theory current hardware should be able to support YUV textures hardware-wise without any trouble (just some kind of automatic shaders would be needed)... Greetings, Reimar D?ffinger
D Richard Felker III wrote:
I just tested the output with MPlayer, not any hardware. I don't think I have access to any hardware that's picky enough to care..
For the reference, telecine2.
I still have two doubts. 1) at the moment telecining is applied to frames in decoding order: to me it seems natural to apply it to frames in display order, or is it wrong?
Yes...this is a major problem, dammit. I've said it 1000 times it feels like, but I'll say once again: I FUCKING HATE B FRAMES!!!!!!!
Whoever came up with such idiocy should be tied to heavy rocks and thrown into a huge vat of cola!!
2) actually timestamps are not modified after telecining, but wouldn't the player get momentarily out of sync in the course of a second (although the user might not nitice)? Should I recalculate frame duration and pts after telecining?
Perhaps. MPEG pts handling is really broken and I don't understand it, so I'll leave it up to you or someone else to figure it out. If you can find an easy way to do it, it probably should be done.
Rich
it was too good to be true :( I will try to fix both issues. I agree with you: b frames are good only to make things complicate and to spoil the image. Nico
D Richard Felker III wrote:
I still have two doubts. 1) at the moment telecining is applied to frames in decoding order: to me it seems natural to apply it to frames in display order, or is it wrong?
Yes...this is a major problem, dammit. I've said it 1000 times it feels like, but I'll say once again: I FUCKING HATE B FRAMES!!!!!!!
Whoever came up with such idiocy should be tied to heavy rocks and thrown into a huge vat of cola!!
should be fixed in cvs, as long as there are no more than 4 consecutive b-frames. Unfortunately it's not always possible to determine a wrap-around, because some idiot decoded that the gop header (0x18b) is optional, so there is a hack in the video parser. I removed telecine2 and left only telecine that sets progressive frame and unsets progressive sequence
2) actually timestamps are not modified after telecining, but wouldn't the player get momentarily out of sync in the course of a second (although the user might not nitice)? Should I recalculate frame duration and pts after telecining?
Perhaps. MPEG pts handling is really broken and I don't understand it, so I'll leave it up to you or someone else to figure it out. If you can find an easy way to do it, it probably should be done.
Rich
to make things perfect pts shall be recalculated. This is next step
Nico Sabbi wrote:
Perhaps. MPEG pts handling is really broken and I don't understand it, so I'll leave it up to you or someone else to figure it out. If you can find an easy way to do it, it probably should be done.
Rich
to make things perfect pts shall be recalculated. This is next step
done, patch attached: now after telecining the frame duration is recalculated with the new flags. Rich, I tested it only a little and it seems to work. If you believe it's correctly feel free to commit. Nico
On Tue, Mar 01, 2005 at 11:40:29PM +0100, Nico Sabbi wrote:
Nico Sabbi wrote:
Perhaps. MPEG pts handling is really broken and I don't understand it, so I'll leave it up to you or someone else to figure it out. If you can find an easy way to do it, it probably should be done.
Rich
to make things perfect pts shall be recalculated. This is next step
done, patch attached: now after telecining the frame duration is recalculated with the new flags. Rich, I tested it only a little and it seems to work. If you believe it's correctly feel free to commit.
I'm really not familar with mpeg pts semantics or any technical details about mpeg file formats. If you think it's right, commit it. Otherwise wait for one of the experts I suppose. Rich
Now, with this, should I be able to do an '-ofps 30000:1001' to do a straight framerate upsampling (without -vf telecine) without destroying the a/v sync? Or is there something fundamentally wrong with me doing this? Either way, sound sync is badly damaged currently when attempting to do so. -- Debianista!
On Tue, Mar 01, 2005 at 08:11:57PM -0500, Levi Bard wrote:
Now, with this, should I be able to do an '-ofps 30000:1001' to do a straight framerate upsampling (without -vf telecine) without destroying the a/v sync? Or is there something fundamentally wrong with me doing this? Either way, sound sync is badly damaged currently when attempting to do so.
Don't use -ofps 30000/1001. Just treat the whole thing as 24fps (24000/1001) and pass the telecine option to the mpeg muxer. All of the soft-telecine process will happen internally in the muxer; mencoder doesn't know about it at all. If you're asking how to do this without -mpegopts telecine, I can tell you other ways, but now that you have this option it's the best way. Rich
On Wed, Feb 23, 2005 at 06:27:49PM -0500, D Richard Felker III wrote:
ok, at some point someone should make a guide for how to encode (compliant) vcd/svcd/dvd with mencoder's new mpeg muxer.
I agree. I'm playing with some things at the moment, but none of it final, and none of it as good as TMPGenc. (Although it is twice as fast. :)
- i seem to occasionally get weird out-of-order glitched frames during really high motion scenes. is this due to buggy reordering of some sort in the muxer, failure to enforce closed gops, or something else? i think i can extract small samples that exhibit the problem if you want to see one.
I've noticed this in some of my home-made DVDs. I dug through the source MPEGs, and the problem lies there. The source is interlaced NTSC MPEG2 from a Tivo, and there are (rarely, but noticably) missing fields. Any correct way to deal with that other than a blurring deinterlace filter? I've never really liked the way those look. I'm having compilance issues with dvd format, too. I specified format=dvd under mpegopts, but my dvd authoring app doesn't like the streams. Doesn't say why, mind you... :( Also, mencoder wants to screw up audio sync pretty badly from my Tivo recordings. After an hour, I'm a whole scene off. The story is: -ovc lavc -lavcopts vcodec=mpeg2 complains that "2997 / 100" is not a valid framerate for mpeg. which is stupid, because the source file is an mpeg. it's upset over rounding and conversion errors introduced by the mplayer core itself. (somewhere) I'm not able to fix this off-hand. -ovc lavc -lavcopts vcodec=mpeg2 -ofps 30000/1001 encodes, but with massive audio sync problems. -ovc lavc -lavcopts vcodec=mpeg2 -fps 30000/1001 -ofps 30000/1001 encodes, same sync problems. -ovc lavc -lavcopts vcodec=mpeg2 -mpegopts vframerate=30000/1001 dies the same as without -ofps. -ovc lavc -lavcopts vcodec=mpeg2:vstrict=-1 encodes fine, and sync is almost correct. (barely noticable desync after an hour.) why? when this one is done, the terminal has lots of warnings about duplicate and dropped frames. is this a neccessary process to cope with what is really a somewhat variable framerate source? is this process somehow screwed up by -ofps/-fps? if these flags are screwing it up we should either document the vstrict trick or fix the encoder so that we don't need to "trick" it into accepting a "nonstandard" framerate. I vote for the second, but I can't find the right fix. And I still can't help but feel like I'm missing something very fundamental and important. Am I just mad, or is this really hard? --Joey -- "Of the seven dwarves, the only one who shaved was Dopey. That should tell us something about the wisdom of shaving."
On Wed, Feb 23, 2005 at 11:00:13PM -0600, Joey Parrish wrote:
- i seem to occasionally get weird out-of-order glitched frames during really high motion scenes. is this due to buggy reordering of some sort in the muxer, failure to enforce closed gops, or something else? i think i can extract small samples that exhibit the problem if you want to see one.
I've noticed this in some of my home-made DVDs. I dug through the source MPEGs, and the problem lies there. The source is interlaced NTSC MPEG2 from a Tivo, and there are (rarely, but noticably) missing fields. Any correct way to deal with that other than a blurring deinterlace filter? I've never really liked the way those look.
Missing fields?? What do you mean? This is a different problem from what I was experiencing.
I'm having compilance issues with dvd format, too. I specified format=dvd under mpegopts, but my dvd authoring app doesn't like the streams. Doesn't say why, mind you... :(
You also have to use the right parameters to the mpeg video encoder..
Also, mencoder wants to screw up audio sync pretty badly from my Tivo recordings. After an hour, I'm a whole scene off. The story is:
-ovc lavc -lavcopts vcodec=mpeg2 complains that "2997 / 100" is not a valid framerate for mpeg. which is stupid, because the source file is an mpeg. it's upset over rounding and conversion errors introduced by the mplayer core itself. (somewhere) I'm not able to fix this off-hand.
Try -ofps 30000/1001
-ovc lavc -lavcopts vcodec=mpeg2 -ofps 30000/1001 encodes, but with massive audio sync problems. [...] And I still can't help but feel like I'm missing something very fundamental and important. Am I just mad, or is this really hard?
OK, you did. Also use harddup as the last filter in your filter chain. If you're not using it and seeing any "duplicate frame" messages whatsoever, a/v sync is being horribly ruined in your output file. Rich
On Thu, Feb 24, 2005 at 12:57:38AM -0500, D Richard Felker III wrote:
On Wed, Feb 23, 2005 at 11:00:13PM -0600, Joey Parrish wrote:
- i seem to occasionally get weird out-of-order glitched frames during really high motion scenes. is this due to buggy reordering of some sort in the muxer, failure to enforce closed gops, or something else? i think i can extract small samples that exhibit the problem if you want to see one.
I've noticed this in some of my home-made DVDs. I dug through the source MPEGs, and the problem lies there. The source is interlaced NTSC MPEG2 from a Tivo, and there are (rarely, but noticably) missing fields. Any correct way to deal with that other than a blurring deinterlace filter? I've never really liked the way those look.
Missing fields?? What do you mean? This is a different problem from what I was experiencing.
According to an MPEG parser in my DVD authoring app, the frames are: X+0. top X+1. bottom X+2. top X+3. top X+4. bottom within the same GOP. I have no clue what this is about, I'm only now learning about MPEG internals of out neccessity over the past few months.
I'm having compilance issues with dvd format, too. I specified format=dvd under mpegopts, but my dvd authoring app doesn't like the streams. Doesn't say why, mind you... :(
You also have to use the right parameters to the mpeg video encoder..
Yes, keyint=15 fixed that. Thanks.
Also, mencoder wants to screw up audio sync pretty badly from my Tivo recordings. After an hour, I'm a whole scene off. The story is:
-ovc lavc -lavcopts vcodec=mpeg2 complains that "2997 / 100" is not a valid framerate for mpeg. which is stupid, because the source file is an mpeg. it's upset over rounding and conversion errors introduced by the mplayer core itself. (somewhere) I'm not able to fix this off-hand.
Try -ofps 30000/1001
-ovc lavc -lavcopts vcodec=mpeg2 -ofps 30000/1001 encodes, but with massive audio sync problems. [...] And I still can't help but feel like I'm missing something very fundamental and important. Am I just mad, or is this really hard?
OK, you did. Also use harddup as the last filter in your filter chain. If you're not using it and seeing any "duplicate frame" messages whatsoever, a/v sync is being horribly ruined in your output file.
I've been trying with/without harddup, with/without noskip, with/without audio re-encoding, etc. I still can't get any better than what I've listed above. Noticable (less than 1 sec) desync after 30-60 minutes. --Joey -- "I can read it better than you can read it with your eyes closed." --Gu
Joey Parrish wrote:
I've been trying with/without harddup, with/without noskip, with/without audio re-encoding, etc. I still can't get any better than what I've listed above. Noticable (less than 1 sec) desync after 30-60 minutes.
--Joey
can you post sample and filename[s] please?
On Wed, 23 Feb 2005, Joey Parrish wrote:
-ovc lavc -lavcopts vcodec=mpeg2 complains that "2997 / 100" is not a valid framerate for mpeg.
The lavc float to fraction code strikes again!
which is stupid, because the source file is an mpeg. it's upset over rounding and conversion errors introduced by the mplayer core itself. (somewhere) I'm not able to fix this off-hand.
mplayer doesn't have the exact correct framesrates for mpeg files (too few significant digits), and then it (stupidly) converts frame-rates to a 32-bit float, which is then converted back into a (different) fraction by code in lavc. This can't be fixed, as certain people don't believe it happens.
On Feb 21, 2005, at 4:50 PM, Nico Sabbi wrote:
committed with the following changes: - packs are written only when totally full: reduces overhead and makes xvcd finally work; typical overhead seems to be < 2% for dvd, <1.7% for [s]vcd, < 1.2% for generic mpeg - initial system header updated at the second call of muxer_write_header, as did the original mpeg muxer - removed all changes in mencoder.c and the new_osh* in muxer.c
Man patch to follow later
The output of "mencoder -ovc copy -o m84menc.mpg -of mpeg m84_1.mpg" (from http://hubblesource.stsci.edu/sources/video/clips/details/lg-blk- hole.php) doesn't open in QuickTime Player, although it works in VLC and Mplayer; this is on MacOS X. I uploaded it to http://astrange.ithinksw.net/etc/m84menc.mpg. Since everything else I have seems to think it's a real MPEG-1 file, I'll probably file it as a bug at Apple's website.
Alexander Strange wrote:
The output of "mencoder -ovc copy -o m84menc.mpg -of mpeg m84_1.mpg" (from http://hubblesource.stsci.edu/sources/video/clips/details/lg-blk- hole.php) doesn't open in QuickTime Player, although it works in VLC and Mplayer; this is on MacOS X.
I uploaded it to http://astrange.ithinksw.net/etc/m84menc.mpg.
Since everything else I have seems to think it's a real MPEG-1 file, I'll probably file it as a bug at Apple's website.
without option -mpegopts format=mpeg1 the new muxer now defaults to mpeg2 format
participants (15)
-
Alexander Strange -
Andriy N. Gritsenko -
Arpi -
D Richard Felker III -
Giacomo Comes -
Guillaume Poirier -
Jeff -
Joey Parrish -
Levi Bard -
Michael Niedermayer -
Nico Sabbi -
Reimar D�ffinger -
Roine Gustafsson -
Trent Piepho -
Zoltan Hidvegi