mencoder cvs now with avisynth support

[sherpya]

For daily builders, I suggest to update my avisynth patch, since it eats all memory if opening a big mpg file, also I have other patches and updated builds (with amr/x264)

http://oss.netfarm.it/mplayer-win32.php

[hellfred]

Originally posted by sherpya
For daily builders, I suggest to update my avisynth patch, since it eats all memory if opening a big mpg file, also I have other patches and updated builds (with amr/x264)

http://oss.netfarm.it/mplayer-win32.php

Hi sherpya
I know that you have submittet your patch to the mplayer dev-cygwin mailing list. Why was your patch not comitted? Are you still working on it?

hellfred

[hellfred]

Seven hours ago, demuxing support for avs was added to mplayers cvs.
Afaik it will automatically be enabled in ./configure as long as you are compiling mplayer/mencoder for win32.

Hellfred

[bond]

what about mencoder?

[hellfred]

Originally posted by bond
what about mencoder?
Should read through avs just fine. Those are sherpya's patches finally committed to cvs. I have to finisch my Diploma thesis right now, so no time for playing around :(

Hellfred

[bond]

Originally posted by hellfred
Should read through avs just fine. Those are sherpya's patches finally committed to cvs.great!

I have to finisch my Diploma thesis right now, so no time for playing around :( have fun ;)

[opsis81]

http://4nykey.nm.ru/bin/mplayer-cvs.exe
If your browser can't download it go to http://4nykey.nm.ru/bin/ first.
It's a 12-Feb-2005 cvs build.
It includes mplayer,mencoder and gmplayer.
All codecs and native avisynth support are enabled.
I'm waiting for a new MeGUI version with xvid and x264 support and without the need of avs2yuv.Don't dissapoint me Doom9;)

[celtic_druid]

Well I put up new compiles earlier today with x264 Revision 124.

[opsis81]

Try again bond.
Sometimes this site goes offline but then it returns again.
It's a very good site because it always has the latest cvs builds for mplayer,ffmpeg2theora,ffmpeg and avidemux.

[JoeBG]

Originally posted by celtic_druid
Well I put up new compiles earlier today with x264 Revision 124. Thanks a lot.

[bond]

ok i now splitted that avs+mencoder discussion to an own thread :)

i tried that feature (with CD's latest build) while encoding to x264 and it doesnt seem to work
after the message "x264 [info]: no need for a SAR" i get a crash in kernel32.dll

i use winme on a pentium3 866mhz

[Sharktooth]

uhm... last time i tried (about 3 weeks ago) it worked...
maybe it's winme... :D

[bond]

Originally posted by Sharktooth
uhm... last time i tried (about 3 weeks ago) it worked...
maybe it's winme... :D hm, seems to be the Athlon-64 optimisation, .vob input also doesnt work
also an older Athlon-64 compile shows the same results

the mplayer2005.01.20.Athlon-XP-AVS.7z compile on the other side works great with .vob and .avs input

[Sharktooth]

IIRC i tried the athlon 64 build, or maybe i confused the athlon 64 with the athlon xp build...

[JoeBG]

I always use celticdruids P4 compiles with MeGui

With short clips I don´t have any problems with the mencoder from 1 February. But when I want to start a real long movie, MeGUI freezes. When I stop the system, mencoder works in the background. I can see it in the taskmanager. But he only starts when I stop MeGUI.

It works very well with mencoder from the middle of January - so I thought it´s because of mencoder. Has anyone the same experiences?

[bond]

CD uploaded an xp compile which works great here! thanks :)

actually it seems the avs handling of mencoder doesnt handle being fed yv12 (actually the big advantage of avisynth 2.5 was to be able to pass yv12 without the need for a colorconversion)
whenever i use yv12 i get a blueish picture output
when i use "converttoyuy2()" in the script it works fine

when i try to specify the yv12 format via "-vf format=yv12" i get a "the selected video_output device is incompatible with this codec. cannot find codec matching selected -vo and video format 0xsomenumbers"

probably i have to use another -vo to make yv12 work? any ideas?

[celtic_druid]

Just encoded a simple YV12 test pattern (colorbars(352,288).converttoYV12() kind of thing) and the colours look fine.

[bond]

Originally posted by celtic_druid
Just encoded a simple YV12 test pattern (colorbars(352,288).converttoYV12() kind of thing) and the colours look fine. colorbars(352,288).converttoYV12() works fine here too, but not a simple
LoadPlugin("C:\...\DGDecode.dll")
mpeg2source("C:\...\source.d2v")
trim(0,50)
crop(0,82,720,416)
LanczosResize(640,256)btw i get the same results with the ffdshow and videosoft decoder (tested in graphedit to avoid that a player related issue kicks in)

[virus]

Originally posted by bond
colorbars(352,288).converttoYV12() works fine here too, but not a simple
...
(script)
...
btw i get the same results with the ffdshow and videosoft decoder (tested in graphedit to avoid that a player related issue kicks in)
I can confirm everything. With YV12 I get swapped chroma planes in the output. The only workaround is to use SwapUV() at the end of the script.

With YUY2 it works, but obviously there's no point in doing 2 extra colorspace conversions. I'll stick with avs2yuv for now.

...so, patch b0rked :(

[celtic_druid]

Just when using mpeg2source as far as I can tell. Tried with avisource() and it was fine as was colorbars. even mpeg2source().converttoyuy2().converttoyv12() is fine so it isn't simply a matter of YV12.

[Wilbert]

I don't know if it makes any sense. But I guess the colorformat I420 is not supported (by mencoder ?). IIRC mpeg2dec3 is actually outputting I420. I will point neuron2 to this thread.

[virus]

Originally posted by Wilbert
I don't know if it makes any sense. But I guess the colorformat I420 is not supported (by mencoder ?). IIRC mpeg2dec3 is actually outputting I420. I will point neuron2 to this thread.
If this is true, then the problem lies in /libmpdemux/demux_avs.h, line 151. That macro avs_is_yv12() assumes that I420 and YV12 are the same thing, but they obviously aren't (swapped chroma planes).

The patch seems to convert automatically whatever non-YV12 video returned by the script to YV12, but if the input is I420 there's no conversion due to the reason above.

[sherpya]

my avisynth demuxer patch expects YV12 video, if not it will automatically call ConvertToYV12() fuction over the resulting clip.
Other colorspaces can be added as well, but I'm not a colorspace expert and so I've used the simplest way :). Anyway most of the encoded stuff should be yv12

[bond]

sherpya, still yv12 input doesnt work correctly!

[opsis81]

yes bond this is so true:(
I have tested three different cvs compiles with the exact same blueish results.
I hope mplayer developers will fix it soon.
Has anybody got in contact with any of them?

[sh0dan]

If you are depending on the order of U&V, you are most likely interfacing wrongly with AviSynth. If you need a complete YV12 planar frame, you must create it yourself and blit each plane separately. Otherwise you are very likely to run into (other) problems.

AviSynth has transparent YV12/I420 support, since both return the U-plane when you use PVideoFrame->GetReadPtr(PLANAR_U).

[neuron2]

I made a new version of DGDecode.dll that outputs YV12 by default. You can switch it to I420 with i420=true. Please tell me if it cures the problem.

http://neuron2.net/dgmpgdec/DGDecode121b2.zip

[opsis81]

Yes it does:D ,for me at least

[Sharktooth]

Confirmed.

[neuron2]

Great. Thank you very much for your test results.

[virus]

I appreciate neuron2's efforts to workaround the b0rk in someone else's code, but imho the problem should be corrected in mencoder itself. It should run on existing scripts without the need for updating DGDecode or changing the script.

Currently the patch doesn't work for at least 2 reasons:
1) doesn't distinguish properly YV12 and I420
2) calls ConvertToYV12, which is not sufficient (apparently) to do I420->YV12. As Celtic Druid pointed out, you need converttoyuy2.converttoyv12 to do that (and this is a waste).

A simple workaround to the current code would be to (correctly) recognize I420 and call SwapUV. I think that would require just little changes. A better workaround would be to redesign the patch, using maybe avs2yuv as base, since it correctly works with existing scripts (I haven't checked how avs2yuv works internally, though).

[neuron2]

I agree that mencoder should be fixed. But it is also a good thing in itself that DGDecode now outputs YV12, so that it is consistent with the other source filters that claim to output YV12.

[bond]

Originally posted by neuron2
I agree that mencoder should be fixed. But it is also a good thing in itself that DGDecode now outputs YV12, so that it is consistent with the other source filters that claim to output YV12. yep :)

and yep works fine with mencoder

[bond]

so any chance that the I420 input bug gets fixed?

sherpya?

[virus]

Originally posted by bond
so any chance that the I420 input bug gets fixed?

sherpya?
yeah, that patch is 2 times b0rked. It messes with I420, and also seems to produce an extra (duplicate) frame at the end of the encode (both encoding with bvops or without, same result).

The solution is to rewrite the code that grabs a frame from the script using avs2yuv's code as base; avs2yuv has none of these issues. It calls converttoyv12() when needed like mencoder's patch but then it works as sh0dan described, by using GetPitch and GetReadPtr to read the planes one after the other, for each frame.

Can some Avisynth expert have a look at /libmpdemux/demux_avs.c? It's clear that the original author couldn't care less about fixing his own bugs :(