On Wed, 26 Mar 2025 02:38:01 +0100,
Brad Smith wrote:
>
> On 2025-03-20 10:29 a.m., Kirill A. Korinsky wrote:
>
> > Brad,
> >
> > I had discover that ffplay / ffmpeg may crash when I detach webcam from a
> > machine. I had run it with command like:
> >
> > ffplay -i /dev/video0 -input_form
On 2025-03-20 10:29 a.m., Kirill A. Korinsky wrote:
Brad,
I had discover that ffplay / ffmpeg may crash when I detach webcam from a
machine. I had run it with command like:
ffplay -i /dev/video0 -input_format mjpeg -video_size 1920x1080
-framerate 30
and after I detach it crashes. No
Brad,
I had discover that ffplay / ffmpeg may crash when I detach webcam from a
machine. I had run it with command like:
ffplay -i /dev/video0 -input_format mjpeg -video_size 1920x1080
-framerate 30
and after I detach it crashes. Not always, but I had seen it quite a few
times during my
On Sat Jan 11, 2025 at 08:41:32PM +0100, Jan Stary wrote:
> Should graphics/ffmpeg include an explicit --enable-vaapi ?
> The current Makefile seems to rely on autodetection, is that intended?
>
> Jan
>
Yes, auto-detection is provided, and since we ship libva with xenoca
Should graphics/ffmpeg include an explicit --enable-vaapi ?
The current Makefile seems to rely on autodetection, is that intended?
Jan
I think you should give up on this.
I think by talking about "sandbox" in an abstract for what is going on,
it fails to describe the what is going on. "sandbox" is an extremely
unspecific words and everyone brings in their weird understanding.
- the program (firefox) has extremely poor "privsep"
Le Wed, Aug 14, 2024 at 10:57:46AM +0200, Jan Stary a écrit :
> > Can AMD users play https://www.youtube.com/watch?v=LXb3EKWsInQ in
> > 2160p60 on FF without blowing the CPU?
>
> On this AMD machine (dmesg and vainfo below),
> firefox-129.0 plays this video eating about 14% of CPU.
>
> PID USER
To be sure: is vaapi supposed to also help with encoding ?
$ pkg_info intel-vaapi-driver
The current video driver backend provides a bridge to the GEN GPUs
through the packaging of buffers and commands to be sent to the i915
driver for exercising both hardware and shader functionality for
> First, I was able to solve my problem with acceleration in Firefox
> using this about:config option
>
> media.ffmpeg.vaapi.enabled = true
>
> Once I enabled it, in about:support I saw h264 hardware decoding
> support (but not h265 and my card is capable).
Setting media.ffmpeg.vaapi.enabled = t
> Can AMD users play https://www.youtube.com/watch?v=LXb3EKWsInQ in
> 2160p60 on FF without blowing the CPU?
On this AMD machine (dmesg and vainfo below),
firefox-129.0 plays this video eating about 14% of CPU.
PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND
23106 hans
On Mon, Jul 29, 2024 at 01:52:51PM GMT, Jan Stary wrote:
> On Jul 21 18:00:28, lu...@sexy.is wrote:
> > On Sun, Jul 21, 2024 at 01:09:24PM GMT, José Maldonado wrote:
> > > This is rare. In my case, using mpv+yt-dlp for YouTube videos work
> > > fine (using 4.4.4p3 and 4.4.4p5).
> >
> > This isn't
On Jul 21 14:15:49, josemal...@gmail.com wrote:
> El dom, 21 jul 2024 a la(s) 2:00 p.m., Lucas Gabriel Vuotto
> (lu...@sexy.is) escribió:
> >
> > I don't believe you're doing hardware decoding here. This is how it
> > looks in my machine:
> >
> > (+) Video --vid=1 (*) (vp9 3840x2160 59.940fps)
> >
On Jul 28 20:19:48, raf...@sizeofvoid.org wrote:
> On Sun Jul 28, 2024 at 06:52:04PM GMT, Jan Stary wrote:
> > On Jul 28 18:37:55, raf...@sizeofvoid.org wrote:
> > > On Sun Jul 28, 2024 at 06:35:37PM GMT, Jan Stary wrote:
> > > > Before I get down the rabbit hole,
> > > > is there any way to tell w
El dom, 28 jul 2024 a la(s) 4:59 a.m., Landry Breuil
(lan...@openbsd.org) escribió:
>
> Le Sun, Jul 28, 2024 at 09:43:55AM +0200, Landry Breuil a écrit :
>
> with the latest version of the patchset, i have something that doesnt
> crash, but fails to properly initialize vaapi:
>
> [(null) 51070: Mai
On Sun Jul 28, 2024 at 06:52:04PM GMT, Jan Stary wrote:
> On Jul 28 18:37:55, raf...@sizeofvoid.org wrote:
> > On Sun Jul 28, 2024 at 06:35:37PM GMT, Jan Stary wrote:
> > > Before I get down the rabbit hole,
> > > is there any way to tell which codecs
> > > my inteldrm is able to decode/accelerate
On Jul 28 18:37:55, raf...@sizeofvoid.org wrote:
> On Sun Jul 28, 2024 at 06:35:37PM GMT, Jan Stary wrote:
> > Before I get down the rabbit hole,
> > is there any way to tell which codecs
> > my inteldrm is able to decode/accelerate
> > and how much it is worth it?
cd /usr/ports/sysutils/libva-uti
On Sun Jul 28, 2024 at 06:35:37PM GMT, Jan Stary wrote:
> Before I get down the rabbit hole,
> is there any way to tell which codecs
> my inteldrm is able to decode/accelerate
> and how much it is worth it?
cd /usr/ports/sysutils/libva-utils && make install && vainfo
>
> Anything else to look at
Before I get down the rabbit hole,
is there any way to tell which codecs
my inteldrm is able to decode/accelerate
and how much it is worth it?
Anything else to look at besides this?
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 2000" rev 0x09
Jan
OpenBSD 7.5-current (GENERIC.MP)
Landry Breuil wrote:
> thanks, that's a start, because it makes us understand what files are
> opened by which process.
>
> But you do realize this adds lots of capacities to those process types
> that arent needed right now, thus shouldnt be added.
That is correct. What's being proposed is ve
Le Sun, Jul 28, 2024 at 09:43:55AM +0200, Landry Breuil a écrit :
> Le Fri, Jul 26, 2024 at 08:49:49PM -0400, José Maldonado a écrit :
> > El vie, 26 jul 2024 a la(s) 8:56 a.m., Landry Breuil
> > (lan...@openbsd.org) escribió:
> > >
> > > > There are numerous issues that will need to be fixed befor
Le Fri, Jul 26, 2024 at 08:49:49PM -0400, José Maldonado a écrit :
> El vie, 26 jul 2024 a la(s) 8:56 a.m., Landry Breuil
> (lan...@openbsd.org) escribió:
> On the other hand, there is one additional positive point in creating
> the libgbm and libdrm symlinks (or patch hardcode name for this lib
Le Fri, Jul 26, 2024 at 08:49:49PM -0400, José Maldonado a écrit :
> El vie, 26 jul 2024 a la(s) 8:56 a.m., Landry Breuil
> (lan...@openbsd.org) escribió:
> >
> > > There are numerous issues that will need to be fixed before va-api in
> > > firefox will actually work. Some of them are pledge/unveil
El vie, 26 jul 2024 a la(s) 8:56 a.m., Landry Breuil
(lan...@openbsd.org) escribió:
>
> > There are numerous issues that will need to be fixed before va-api in
> > firefox will actually work. Some of them are pledge/unveil related,
> > others are firefox hardcoding specific library versions for dlo
That's quite a step backwards for pledge usage. The firefox privsep
story just keeps getting worse.
El mié, 24 jul 2024 a la(s) 4:41 p.m., Rafael Sadowski
(raf...@sizeofvoid.org) escribió:
>
> On Sat Jul 20, 2024 at 11:32:29AM GMT, Rafael Sadowski wrote:
> > OK to enable VA-API? It only depends on xenocara libva. Since libva
> > builds on almost all arches, I see no reason to restrict it by CPU
>
On Sat Jul 20, 2024 at 11:32:29AM GMT, Rafael Sadowski wrote:
> OK to enable VA-API? It only depends on xenocara libva. Since libva
> builds on almost all arches, I see no reason to restrict it by CPU
> architectures any further.
>
Here is some research from me:
# Case 1, segmentation fault in int
El mié, 24 jul 2024 a la(s) 2:01 a.m., Rafael Sadowski
(raf...@sizeofvoid.org) escribió:
>
> On Sun Jul 21, 2024 at 04:58:15PM GMT, Lucas Gabriel Vuotto wrote:
> > On Sat, Jul 20, 2024 at 11:32:29AM GMT, Rafael Sadowski wrote:
> > > OK to enable VA-API? It only depends on xenocara libva. Since libv
On Tue Jul 23, 2024 at 06:02:20PM GMT, José Maldonado wrote:
>
> Hi!
>
> The last sync (23 july, 21:57 pm UTC) for my port tree have
> ffmpeg-4.4.4p5 without VAAPI active (--disable-vaapi CONFIGURE_ARGS)
> but ports xine-libs and others point this version with this support.
>
Thanks for feedbac
On Sun Jul 21, 2024 at 04:58:15PM GMT, Lucas Gabriel Vuotto wrote:
> On Sat, Jul 20, 2024 at 11:32:29AM GMT, Rafael Sadowski wrote:
> > OK to enable VA-API? It only depends on xenocara libva. Since libva
> > builds on almost all arches, I see no reason to restrict it by CPU
> > architectures any fu
architectures any further.
>
> diff --git a/graphics/ffmpeg/Makefile b/graphics/ffmpeg/Makefile
> index 8b1663a55ab..83887bbabe0 100644
> --- a/graphics/ffmpeg/Makefile
> +++ b/graphics/ffmpeg/Makefile
> @@ -3,7 +3,7 @@ COMMENT= audio/video converter and streamer
> V= 4.4
On 2024-07-20 5:32 a.m., Rafael Sadowski wrote:
OK to enable VA-API? It only depends on xenocara libva. Since libva
builds on almost all arches, I see no reason to restrict it by CPU
architectures any further.
diff --git a/graphics/ffmpeg/Makefile b/graphics/ffmpeg/Makefile
index 8b1663a55ab
> El dom, 21 jul 2024 a la(s) 2:00 p.m., Lucas Gabriel Vuotto
> (lu...@sexy.is) escribió:
> >
> > I don't believe you're doing hardware decoding here. This is how it
> > looks in my machine:
> >
> > (+) Video --vid=1 (*) (vp9 3840x2160 59.940fps)
> > (+) Audio --aid=1 --alang=eng (*) (aac 2ch 441
El dom, 21 jul 2024 a la(s) 2:00 p.m., Lucas Gabriel Vuotto
(lu...@sexy.is) escribió:
>
> I don't believe you're doing hardware decoding here. This is how it
> looks in my machine:
>
> (+) Video --vid=1 (*) (vp9 3840x2160 59.940fps)
> (+) Audio --aid=1 --alang=eng (*) (aac 2ch 44100Hz)
> Sub
On Sun, Jul 21, 2024 at 01:09:24PM GMT, José Maldonado wrote:
> This is rare. In my case, using mpv+yt-dlp for YouTube videos work
> fine (using 4.4.4p3 and 4.4.4p5).
This isn't firefox tho, which is were I do experience issues. My
ffmpeg+mpv works fine, even mpv+yt-dlp with your YouTube video.
ff
El dom, 21 jul 2024 a la(s) 1:00 p.m., Lucas Gabriel Vuotto
(lu...@sexy.is) escribió:
>
> On Sat, Jul 20, 2024 at 11:32:29AM GMT, Rafael Sadowski wrote:
> > OK to enable VA-API? It only depends on xenocara libva. Since libva
> > builds on almost all arches, I see no reason to restrict it by CPU
> >
On Sat, Jul 20, 2024 at 11:32:29AM GMT, Rafael Sadowski wrote:
> OK to enable VA-API? It only depends on xenocara libva. Since libva
> builds on almost all arches, I see no reason to restrict it by CPU
> architectures any further.
This worked well with mpv but is giving me issues in Firefox:
- In
El sáb, 20 jul 2024 a la(s) 5:34 a.m., Rafael Sadowski
(raf...@sizeofvoid.org) escribió:
>
> OK to enable VA-API? It only depends on xenocara libva. Since libva
> builds on almost all arches, I see no reason to restrict it by CPU
> architectures any further.
>
> diff --git
OK to enable VA-API? It only depends on xenocara libva. Since libva
builds on almost all arches, I see no reason to restrict it by CPU
architectures any further.
diff --git a/graphics/ffmpeg/Makefile b/graphics/ffmpeg/Makefile
index 8b1663a55ab..83887bbabe0 100644
--- a/graphics/ffmpeg/Makefile
Hi,
We have marked graphics/ffmpeg (and some ports using it) with USE_NOBTCFI=Yes
as
the library doesn't have proper function annotation regarding IBT on amd64.
But the list of ports using ffmpeg as library is huge:
$ show-reverse-deps -v graphics/ffmpeg | grep LIB_DEPENDS |
On 2022/09/03 10:14, Rafael Sadowski wrote:
> Fix examples installation directory. OK?
> share/examples/ffmpeg/
> +share/examples/ffmpeg/examples/
> +share/examples/ffmpeg/examples/Makefile
> +share/examples/ffmpeg/examples/README
> +share/examples/ffmpeg/examples/avio_list_dir.c
not ok, should
Fix examples installation directory. OK?
Index: Makefile
===
RCS file: /cvs/ports/graphics/ffmpeg/Makefile,v
retrieving revision 1.224
diff -u -p -u -p -r1.224 Makefile
--- Makefile20 Aug 2022 12:29:18 - 1.224
03:06:47 (0%)
-->8--
ok?
Index: Makefile
=======
RCS file: /cvs/ports/graphics/ffmpeg/Makefile,v
retrieving revision 1.187
diff -u -p -r1.187 Makefile
--- Makefile13 Jun 2019 21:03:55 - 1.187
+++ Makefile27 Jun 2019 11:24:22 -0
Audio --aid=1 (aac 2ch 48000Hz)
> [ffmpeg/audio] aac: Input buffer exhausted before END element found
> Error decoding audio.
> AO: [sdl] 48000Hz stereo 2ch s32
> A: 00:00:14 / 03:06:47 (0%)
> -->8--
>
>
> ok?
>
>
> Index: Makefile
> =
======
RCS file: /cvs/ports/graphics/ffmpeg/Makefile,v
retrieving revision 1.187
diff -u -p -r1.187 Makefile
--- Makefile13 Jun 2019 21:03:55 - 1.187
+++ Makefile27 Jun 2019 11:24:22 -
@@ -4,7 +4,7 @@ COMMENT=audio/video converter and strea
Hi Brad,
On Fri, 10 May 2019, Brad Smith wrote:
> Hi Paco,
>
> I saw this, but I forgot to reply.
No worries !
> I'm all for additional functionality, but FFmpeg in particular I have
> been trying to balance functionality, but not try to pull in the
> whole kitchen sink too.
I understand.
>
libraries. If we go in this direction the diff needs a bunch of
additional
changes.
On 5/9/2019 2:38 PM, Paco Esteban wrote:
Hi ports@,
I sent this email to Brad Smith, maintainer of graphics/ffmpeg 2 weeks
ago but did not have any answer.
I'm forwarding it here so maybe somebody
OK kn
On Thu May 09, 2019 at 08:38:00PM +0200, Paco Esteban wrote:
> Hi ports@,
>
> I sent this email to Brad Smith, maintainer of graphics/ffmpeg 2 weeks
> ago but did not have any answer.
>
> I'm forwarding it here so maybe somebody can take a look.
>
> Thanks.
Hi ports@,
I sent this email to Brad Smith, maintainer of graphics/ffmpeg 2 weeks
ago but did not have any answer.
I'm forwarding it here so maybe somebody can take a look.
Thanks.
- Forwarded message -
...
I had a problem the other day trying to watch a video stream using mpv
=
RCS file: /cvs/ports/graphics/ffmpeg/Makefile,v
retrieving revision 1.121
diff -u -p -r1.121 Makefile
--- Makefile26 Jul 2015 07:22:15 - 1.121
+++ Makefile29 Jul 2015 16:07:50 -
@@ -5,6 +5,7 @@ COMMENT=audio/video converter and strea
V=
On 2014-01-27 20:37, Brad Smith wrote:
...I am trying to strike a balance as to what to add
to FFmpeg and what not to add, at least for the default package. I was
also considering adding it as a FLAVOR.
Thank you! Let me know if there is anything I can do to help, even if
it's only the additi
On Mon, Jan 27, 2014 at 7:37 PM, Brad Smith wrote:
> On 22/01/14 10:22 PM, Josh Grosse wrote:
>
>> The following minor proposed patch adds --enable-libass to ffmpeg.
>> Tested on
>> i386 and it appears to integrate well with the Xenocara fontconfig.
>>
>> I sent this to $MAINTAINER brad@ at his
On 22/01/14 10:22 PM, Josh Grosse wrote:
The following minor proposed patch adds --enable-libass to ffmpeg. Tested on
i386 and it appears to integrate well with the Xenocara fontconfig.
I sent this to $MAINTAINER brad@ at his comstyle address on Friday and as
I've had no reply, I assume he's be
The following minor proposed patch adds --enable-libass to ffmpeg. Tested on
i386 and it appears to integrate well with the Xenocara fontconfig.
I sent this to $MAINTAINER brad@ at his comstyle address on Friday and as
I've had no reply, I assume he's been busy, or the Email is stuck in
greylist
On Tue, Feb 26, 2013 at 22:12, Donovan Watteau wrote:
> Hi,
>
> This is something I've reported a while back [1], and for which I sent
> another email to Brad the day before the ports tree got fully locked
> out of the blue, but unfortunately I didn't get any reply in time for
> the big lock. (I
Hi,
This is something I've reported a while back [1], and for which I sent
another email to Brad the day before the ports tree got fully locked
out of the blue, but unfortunately I didn't get any reply in time for
the big lock. (I would have directly reported it here again if I knew
the full port
On 10/27/2012 3:11 PM, John Long wrote:
I tried building vlc and mplayer from ports and neither build on my
Fuloong. I need to test ffmpeg standalone since I can't get the above 2
working but I didn't want to hold this up since I can confirm ffmpeg builds
cleanly after applying Donovan's patch a
On 10/27/2012 3:11 PM, John Long wrote:
I tried building vlc and mplayer from ports and neither build on my
Fuloong. I need to test ffmpeg standalone since I can't get the above 2
working but I didn't want to hold this up since I can confirm ffmpeg builds
cleanly after applying Donovan's patch a
On Fri, Oct 19, 2012 at 11:10:31PM +0200, Donovan Watteau wrote:
> On Sat, Sep 29, 2012 at 01:45:43PM +0200, Donovan Watteau wrote:
> > Hello,
> >
> > The following diff makes it possible for ffmpeg to be linked
> > on loongson (it used to give "ld: final link failed: Bad value",
> > see [1]), and
On Sat, Sep 29, 2012 at 01:45:43PM +0200, Donovan Watteau wrote:
> Hello,
>
> The following diff makes it possible for ffmpeg to be linked
> on loongson (it used to give "ld: final link failed: Bad value",
> see [1]), and probably sgi too (though I couldn't test this one).
>
> This is done by remov
On Sat, 29 Sep 2012, Brad Smith wrote:
> This is a bug in the compiler. Looking around I believe the fix
> in this PR would resolve the issue. Try working with miod@ to
> have a bug fix applied for the compiler.
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33755
I recompiled GCC with the patch
On Sat, Sep 29, 2012 at 01:45:43PM +0200, Donovan Watteau wrote:
> Hello,
>
> The following diff makes it possible for ffmpeg to be linked
> on loongson (it used to give "ld: final link failed: Bad value",
> see [1]), and probably sgi too (though I couldn't test this one).
>
> This is done by rem
p;m=132691957332463&w=2
Index: patches/patch-configure
=======
RCS file: /cvs/ports/graphics/ffmpeg/patches/patch-configure,v
retrieving revision 1.31
diff -u -p -r1.31 patch-configure
--- patches/patch-configure 12 Sep 2012
463&w=2
Index: patches/patch-configure
=======
RCS file: /cvs/ports/graphics/ffmpeg/patches/patch-configure,v
retrieving revision 1.31
diff -u -p -r1.31 patch-configure
--- patches/patch-configure 12 Sep 2012 08:15:57 - 1.31
+++ patches/patch-configure
On 04/21/10 08:31, Jacob Meuser wrote:
I left the muxer name as "oss". I did this because it is the only
supported audio recording muxer in ffmpeg, so everywhere it talks
about hardware audio recording in the docs, it uses
'-f oss -i'. this will also allow any scripts which use
ffmpeg to record
ss -i /dev/audio) to continue to work
as long as aucat isn't running.
--
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
Index: Makefile
===
RCS file: /cvs/ports/graphics/ffmpeg/Makefile,v
retrieving re
On Mon, Apr 05, 2010 at 08:29:19PM +0600, ??? ? wrote:
> How I can rec 4 video stream from this card parallel (simultaneously) ?
maybe some day we'll have vidcat(1)/vio_open(3) etc, until then,
you can only open one stream per device.
--
jake...@sdf.lonestar.org
SDF Public Access UNIX S
uname -a
OpenBSD localhost 4.6 GENERIC#58 i386
I Install video capture card (HW-104 http://www.shocker.ru/14/20.html)
into my PC with OpenBSD 4.6
Some dmesg:
bktr0 at pci0 dev 10 function 0 "Brooktree BT878" rev 0x11: irq 11
bktr0: Warning - card vendor 0x (model 0x) unknown.
bktr0: D
http://secure.lv/~nikns/stuff/ports/ffmpeg-20070208.diff
Index: ffmpeg/Makefile
===
RCS file: /cvs/ports/graphics/ffmpeg/Makefile,v
retrieving revision 1.25
diff -u -r1.25 Makefile
--- ffmpeg/Makefile 26 Jan 2007 16:03:20 -
DESCR:
Ffmpeg2theora is a simple command line tool to convert media files
to .ogg with Theora video and Vorbis audio streams. It supports
reading any file format that ffmpeg can decode.
Tested on i386. Depends on the update of ffmpeg by Nikns Siankin (and
will not build without it.)
Moritz
Nikns Siankin wrote:
http://secure.lv/~nikns/stuff/ports/ffmpeg-20070110.diff
Tested on i386 (with an added ogg-WANTLIB), with VLC and my ports that I
have in my submit queue. Everything works fine, except that VLC is now
complaining a bit:
vlc:/usr/local/lib/vlc/codec/libquicktime_plugin.s
Hi,
I just started testing this update. More results later, but for now I
just wanted to mention that lib-depends-check wants WANTLIB += ogg for
the bin/ffserver binary.
Thanks for the update.
Moritz
Enables libswscale.
http://secure.lv/~nikns/stuff/ports/ffmpeg-20070110.diff
Index: ffmpeg/Makefile
===
RCS file: /cvs/ports/graphics/ffmpeg/Makefile,v
retrieving revision 1.23
diff -u -r1.23 Makefile
--- ffmpeg/Makefile 2 Dec
On Mon, Dec 11, 2006 at 03:53:23PM +0200, Nikns Siankin wrote:
> Added regression tests.
> Added back external decoders.
>
> relevant portion of the official ChangeLog:
>
> - DV50 AKA DVCPRO50 encoder, decoder, muxer and demuxer
> - TechSmith Camtasia (TSCC) video decoder
> - IBM Ultimotion (ULTI
the older version of the port, which works with
>-current's ffmpeg, of course ... It is already capable of rescaling by
>itself, but not as good and possibly not as fast. Would such a port be
>commitable? If yes, no problem. The ffmpeg2theora port can then be
>updated as soon a
f course ... It is already capable of rescaling by
itself, but not as good and possibly not as fast. Would such a port be
commitable? If yes, no problem. The ffmpeg2theora port can then be
updated as soon as there's an ffmpeg update available.
In any case, I want to request that any up
On 12/14/06, Nikns Siankin <[EMAIL PROTECTED]> wrote:
http://marc.theaimsgroup.com/?l=openbsd-ports&m=116584632732016&w=2
Without swscale. Hovever it can be modified to build libswscale if
it is usefull. I don't know for *what it does*.
However, multimedia/transcode is too outdated to use with u
http://marc.theaimsgroup.com/?l=openbsd-ports&m=116584632732016&w=2
Without swscale. Hovever it can be modified to build libswscale if
it is usefull. I don't know for *what it does*.
However, multimedia/transcode is too outdated to use with updated
ffmpeg.
On Thu, Dec 14, 2006 at 02:34:09PM +010
Hi,
I need an update to ffmpeg that includes its libswscale, and if nobody
is looking into this already, I'd start working on an update.
However, I am unable to provide a reliable download site for a snapshot
tarball of ffmpeg's size. In that area, I'd definitely need some help ...
Moritz
===
RCS file: /cvs/ports/graphics/ffmpeg/Makefile,v
retrieving revision 1.23
diff -u -r1.23 Makefile
--- ffmpeg/Makefile 2 Dec 2006 20:24:17 - 1.23
+++ ffmpeg/Makefile 11 Dec 2006 13:42:44 -
@@ -2,15 +2,16 @@
COMMENT= "audio/video converter and streamer with b
From the "give-him-enough-time-and-he'll-figure-it-out" department:
I just realized that the dependency on xvidcore is not needed:
xvidcore generates mpeg4 compliant streams (fourcc XviD), ffmpeg can
also generate mpeg4 compliant streams (fourcc DivX), and my iPod will
play either of them. I don
This patch causes ffmpeg to depend on faac, faad and xvidcore. This
allows you to transcode to your ipod video with one nice clean
command.
ffmpeg -vcodec xvid -b 350 -qmax 10 -bufsize 4096 -g 300 -acodec aac
-ab 96 -ac 2 -i input.mpg -s 320x240 output.mp4
gtkpod is able to load these files and
4 and
> > just a little on i386.
> >
> > I've also included patches for the ports that depend on FFmpeg,
> > (multimedia/libquicktime, multimedia/transcode, x11/vlc),
> > because libavcodec depends on a new set of libraries.
> >
> > please review/test
I have been testing FFmpeg snapshots pretty heavily on amd64 and
> just a little on i386.
>
> I've also included patches for the ports that depend on FFmpeg,
> (multimedia/libquicktime, multimedia/transcode, x11/vlc),
> because libavcodec depends on a new set
s on a new set of libraries.
please review/test/comment, and give me OKs :)
--
<[EMAIL PROTECTED]>
Index: graphics/ffmpeg/Makefile
===
RCS file: /cvs/ports/graphics/ffmpeg/Makefile,v
retrieving revision 1.18
diff -u -r1.18 Makef
85 matches
Mail list logo