Hi Luya,
I'm afraid, that's not a feasible solution for blender.
To support robust frame exact seeking, we have to do some creative stuff
with the ffmpeg API, which is to my knowledge not possible with
gstreamer, I'm afraid.
Suggestion: why don't you build a stripped down version of ffmpeg for
F
Hi Björn,
I haven't bisected my way through it yet, but I'm currently using
Blender 2.66 for editing,
since there have been a lot of changes that caused serious slow downs in
between (at least
in the 8-bit pipeline).
Regarding frameshift: do you use timecodes? If you don't do that, you
will get o
lator class, that derives from
PhabricatorBaseEnglishTranslation and just does the blenderish renaming
and everything should be in place.
Regards,
Peter
--
Peter Schlaile
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
server bug to me
(the one fixed, also wasn't assigned to me) and: I can't find any bugs in
the bug tracker regarding the frameserver.
> So, any volunteers?
Please assign bugs in the current code to me.
And: as I mentioned, if someone finds time to write a python add-on replacemen
Hi Campbell,
> Its helpful to remove because we shouldn't give users options that are
> not useful/tested/ready-for-production...
> When you use software and get the impression that some parts are not
> maintained - they crash or just fail, it doesn’t inspire confidence
> you want when relying on
Hi,
two weeks ago, I wrote something about an inpaint node and why it is
necessary to implement something like the nuke IBK-Keyer using Blender
nodes.
Well:
Following the ideas mentioned in this blog post (you have to scroll
down):
http://www.vfxtalk.com/archive/index.php/t-16044.html
"IBK is a
Hi Nate,
forgot a CMake-File entry and to add old compositor node file.
Please git pull and try again!
Cheers,
Peter
> Not currently building for me on 64bit Linux:
> http://www.pasteall.org/33827
--
--
Peter Schlaile
___
Bf-committers m
above), my node should work fairly well. If you want to add
additional inpainting algos, feel free to add a type and activate
custom1 as a type parameter variable.
--
--
Peter Schlaile
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
quot; feature, this was certainly a good
>>> exercise for seeing how such functionality could look like, and to
>>> generate debate over what use cases for this sort of stuff users have.
>>> (It was also a good exercise in exploring how the sequencer works,
>>> though I
tc.)
If I didn't get the problem correctly, just let me know. I really like to
work out a generic solution for that!
Cheers,
Peter
Peter Schlaile
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Hi Brecht,
> Am I right that if you don't enable proxies, this patch basically has
> no effect?
Yupe, that's true. It has a very conservative approach.
> In that case it should be pretty safe to commit before
> 2.58, but still think this could use some good testing on complex
> files.
Agreed.
eeking code.
Please send me an email with the debugging output pasteall-ed, your
ffmpeg version, if you want to report problems.
Otherwise: enjoy!
And: I'm eager to hear your feedback, also code / design suggestions.
Cheers,
Peter
Peter Schlaile
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
, compiler used etc. etc.)
Cheers,
Peter
Peter Schlaile
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
.
>
> Cheers,
> Ralf
>
> [1] http://packages.ubuntu.com/oneiric/ffmpeg
> [2]
> https://launchpadlibrarian.net/72565355/buildlog_ubuntu-oneiric-amd64.blender_2.57.1%2Bsvn36973~oneiric1_FAILEDTOBUILD.txt.gz
>
> 2011/5/28 Dalai Felinto :
>> Thanks Peter, it all working now (windows 3
break anymore.
If it doesn't work out, please send me an email. (And: if you do
so, tell me the exact ffmpeg version you are using, otherwise, I can't
check!)
Cheers,
Peter
P.S.: Sorry for the inconvenience, should have solved that the first time
this way.
:)
>
> Original Message
> Subject: Re: [Bf-committers] SVN commit: /data/svn/bf-blender [36934]
> trunk/blender: == FFMPEG ==
> From: Peter Schlaile
> To: bf-committers@blender.org
> Date: 05/27/2011 05:53 AM
>> ... did I already mention, tha
5new/build/linux2/source/blender/blenkernel/intern/writeffmpeg.o]
> Error 1
> scons: building terminated because of errors.
>
> Thanks for fast reply, mib.
>
>
> Am 27.05.2011, 01:23 Uhr, schrieb Peter Schlaile :
>
>> ... added some version checks again.
>>
>&g
... added some version checks again.
Please try again!
Cheers,
Peter
> Hi, this commit breaks building on opensuse 11.4/64 with scons, system
> ffmpeg is 0.62.
> http://www.pasteall.org/21955
> Cheers, mib.
___
Bf-committers mailing list
Bf-committers
Hi,
> 1) Blender 2.57+, current projects
>
> - Peter Schlaile: are you still available this month? FFmpeg update
> might have issues.
still there. What (additional) issues came up?
There was and are still serious seeking issues caused by the stupid
ffmpeg seeking code within ffmpeg
ome handy some day, but currently we
don't have capture support).
Hope that helps!
Cheers,
Peter
> Haven't noticed that pixelization errors, but size of Blender's ELF
> growed up from 41 to 51 megabytes. Quite noticale, i'll say. I th
nto the
problem, that if the user speeds up a track with say a factor of 100 you
probably don't want to blend *all* input frames into the output frame but
limit the sampling to say 10 inbetween frames. (That's the way Blender
2.49 does it and Blender 2.5 will do it soon using the
es:
class scene_iterator : public iterator {
public:
Frame fetch(float cfra) {
setup_render(cfra);
return render();
}
}
Peter Schlaile
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
?
... it's not about motion blur, it's about retiming.
If CFRA is float, you can retime a scene strip afterwards and have it
render subframe precision frames (read: extrem slowdowns), which are
done the real way, not using fake interpolation.
Cheers,
Peter
Peter Schlaile
Hi Leo,
> On 2010-11-25 19:45, Peter Schlaile wrote:
>> Or, to put it another way: please show a case to me, that *doesn't*
>> work, with a simple "background builder job" system,
>
> That's why I need to involve the main rendering pipeline. I wish
Hi Leo,
> 1. Write a "VSE 2" and create all-new structures?
this will break compatibility with older versions of blender. Should only
be done as a last resort and if you *really* know, what you are doing.
> 2. Create some kind of "compatibility loader" or data import filter
> that converts th
Hi Randall,
please file a bug report, since ffmpeg custom properties were working
in Blender 2.49 .
I have to take a deeper look into the code to see, how they should
reappear in Blender 2.5 (the UI in 2.49 was aehm somewhat strange :) )
and filing a bug report, is a way to make sure, I don't
Hi Leo,
> I've read through the plugin proposal you wrote way back, and I find no
> real issue with it. Why wasn't it implemented? Was it just lack of
> resources, or am I missing something?
lack of resources and some unresolved issues with IPOs. The problem was,
that I thought it was a good ide
ly pretty much a disaster plan.
> You say 'centered on Linux' like that's a bad thing...
My personal opinion as a Debian-only user doesn't matter here. Point is:
Blender is multiplatform, so the plugin system should better be, too...
Don't want to discourage your ef
ters / effect tracks
etc.
And: in comparising to my proposal, it doesn't solve all the interesting
things (API version control, symbol dependencies), adds additional
complexity through XML files and seems to be centered on Linux.
But that's just my first impression, feel free to
> effect
>> strip render/bake would solve your problems? (It could be done in such a
>> way, that the bake function could request arbitrary frames from it's
> input
>> track.)
>
> It would work, but I'd lose the real-time feedback and great UI I was
> h
er didn't run in background
and was more or less a hack.)
Regarding the tools you have written, do you thing, that adding per effect
strip render/bake would solve your problems? (It could be done in such a
way, that the bake function could request arbitrary frames from it's input
track
rgely broken, so most people won't really
notice...)
This will come back shortly as an option for Movie and Image strips.
(Which will be able to adapt to different frame rates directly for free
on the way, since, cfra is now a float :) ...)
Cheers,
Peter
----
Pete
nd let people wonder, how they should make things
work...
Can't say much about the other points, but I think, that removing features
should only be done, if automatic porting to a new feature is possible
within do_versions()...
Cheers,
Peter
Peter Schlaile
___
ould be done correctly! (YUV -> RGB is a lossy operation)
Please don't try to "generalize" things here in the notion "RGB is good
enough for everyone", since that actually doesn't solve the problem.
There should be a path for RGB input, too,
After that, we could take a look, how that can be folded into
the image reader. (optional, but definitely worth the change for
better quality)
To clarify:
now we do: YUV -> RGB -> color change
We *should* do: YUV -> color change
35 matches
Mail list logo
