- add url about a linux driver for a new webcam (topro, 06a2:0003) I found today.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33857 a95241bf-73f2-0310-859d-f6bbb57e9c96
Happens for example when you create a BMediaFile and close it without
committing the header
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33845 a95241bf-73f2-0310-859d-f6bbb57e9c96
to avoid recurring problems during migration of subversion checkouts
(restored binary files that were garbled by subversions during checkout)
* added appropriate svn:mime-type property for problematic (binary) files
* removed a single (mistyped) svn:mimetype property
* dropped svn:eol-style property for cleanup (they all contained 'native')
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33670 a95241bf-73f2-0310-859d-f6bbb57e9c96
The audio decoding in AVDecoder needs this to work at all.
* Set the infoBuffer and infoSize correctly in GetStreamInfo(). At least this
is what I extract from what the AVDecoder expects.
* Use a slightly more precise timeStamp calculation in the Seek() method.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33358 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added TODO about a probable mix-up to use the media_format meta data
because the FFmpeg Reader plug-in forgot to set the info-buffer correctly
from GetStreamInfo().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33355 a95241bf-73f2-0310-859d-f6bbb57e9c96
codec tags in FFmpeg have changed. However, with the FFmpeg AC-3 decoder, I
am no longer getting sound. I suspect it's something to do with the channel
count.
P.S. I should really fix the endianess mess of the codec tags...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32803 a95241bf-73f2-0310-859d-f6bbb57e9c96
last FFmpeg update. This let's WMV videos play again. Tested on GCC4 and
GGC2 builds.
+alphabranch
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32802 a95241bf-73f2-0310-859d-f6bbb57e9c96
- fix error handling in CamDevice.cpp,
- implemented PowerOnSensor() for Sonix,
- add a ProbeByIICSignature method to CamSensor, that takes a list of regs and values to match, as some Linux drivers do,
- add (unfinished, mostly copied from TAS5110C1B) support for TAS5130D1B sensor,
- add (unfinished) support for PAS106 sensor, probe by IIC signature as the Linux driver does,
- add probing by IIC signature for the HV7131E1 sensor as the Linux driver does,
- use -lusb for BeOS (actually ZETA) builds, don't try to use the Haiku USB Kit,
- for the TAS5110C1B sensor, use remove code dup and call SetVideoFrame(), tweaked the values to match those sniffed from the XP driver,
- disabled gain control for now on sonix, doesn't seem to work on all models.
This gets another sonix-based webcam working, partially at least, so if you want to get one to try until UVC works, try this one:
http://www.macally.com/EN/product/ArticleShow.asp?ArticleID=119
We should at least have one webcam supported in the alpha :D
+alphabranch
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32795 a95241bf-73f2-0310-859d-f6bbb57e9c96
* activated ac3 audio file format support
* uses format metadata to keep the codec context extra data (now needed for flac)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32597 a95241bf-73f2-0310-859d-f6bbb57e9c96
GPL mode. Later in the code, the function would only be used in GPL compile mode,
but this fixes the linking in non-GPL mode.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32193 a95241bf-73f2-0310-859d-f6bbb57e9c96
system has been configured to include GPL add-ons. This cannot be switched on
the fly without rebuilding all of the FFmpeg plugin, since the change in the
Jamfile defines will not automatically trigger a rebuild. So if you change your
configuration with regards to --include-gpl-addons, you have to touch config.h
(this commit touches it anyway).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32191 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Enabled WAV muxer.
* Updated configure line in config.h to be closer to what it could have been
to produce the current config.h, but a lot of encoders and muxers are enabled
manually at the moment, so this line wouldn't produce the config.h as is.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32188 a95241bf-73f2-0310-859d-f6bbb57e9c96
confused about what I already compiled here). The sample format was already
specified.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32186 a95241bf-73f2-0310-859d-f6bbb57e9c96
but specify it to 16bits/sample if it's still a wildcard. Make sure to
allocate the scrub buffer with the correct sample size (was hardcoded to 2
bytes per sample).
* In the AVFormatReader, specify the sample format for B_MEDIA_ENCODED_AUDIO.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32185 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Fleshed out the Encoder API to support parameter setters/getters and returning
a BView for configuration. (Not yet sure if this is a good idea.)
BMediaTrack:
* Implemented all but one of the unimplemented methods in BMediaTrack. It should
be working as far as that class is concerned, unless I missed some of the
vision. ReplaceFrames() remains a stub, added a comment on why it probably
stays that way.
* Release the Encoder reference in the destructor.
FFmpeg plugin:
* Refactoring to delay opening the AVCodec until encoding the first chunk,
so that we can still adjust parameters.
* Support adjusting parameters via [Set|Get]EncodeParameters(). Currently,
only quality is supported, added TODOs about supporting the bit_rate setup
versus the automatically calculated bit_rate.
* Extended EncoderDescription by a bit_rate scale. The Encoder calculates the
raw bitrate needed by the current media format, and then divides that
number by the specific codec's bit_rate_scale, while taking into account the
desired quality. This seems to work very well already (tested with MPEG4),
although a lot more parameters could be specified for libavcodec, depending
on the desired quality.
* Enabled the ogg muxer in libavformat, although it is currently still disabled
in MuxerTable.cpp, because it rejects unknown codecs. Added TODO to this
effect.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32124 a95241bf-73f2-0310-859d-f6bbb57e9c96
again. Should fix playback of any file where the ffmpeg plugin was responsible
for sound. (The symptoms were a crash into the debugger because of an unspecified
audio format...)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32107 a95241bf-73f2-0310-859d-f6bbb57e9c96
didn't own.
* We are supposed to open the AVCodecContext in the writer, even though we never
use it. According to libav-users mailing list, this is necessary, since that
will allocate and initialize some structures that are later needed in
av_write_header(). How this is supposed to work for encoders that libavcodec
does not support, or which we don't know how to map, I do not yet know. For
now it doesn't matter and resolves the problem that audio tracks report the
wrong stream duration.
* Some more improvements with regards to what information we need to fill out
and which we don't.
* Use more sensible defaults for the stream bitrate, so that we get better
quality video by default. This and other parameters can be calculated when
we implement setting the quality.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32103 a95241bf-73f2-0310-859d-f6bbb57e9c96
generation for the packets and how I set the time_base in the AVStream and
AVStream->codec structures. This results in the audio streams of the written
files to report a much too long duration.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32064 a95241bf-73f2-0310-859d-f6bbb57e9c96
info is not part of the media_format otherwise.
* Finished enough in the AVFormatWriter and AVCodecEncoder that we can now
actually create AVIs and MPGs and encode MPEG1, MPEG2 and MPEG4 video.
But no audio as of yet. Also, there is no bit-rate/quality setup, so it seems
libavformat is using the least possible bit-rate/quality.
* Enable some more muxers and encoders in the FFmpeg libs.
* Uses pixel format conversion from libswsscale, need to read the documentation
again, but I think it makes the plugin GPL.
* Fixed includes in libswscale/swscale.h, this is now an unmodified FFmpeg 0.5
header again (AFAICT).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32043 a95241bf-73f2-0310-859d-f6bbb57e9c96
media_file_format as input, so that the Writer knows what kind of file is
needed.
* Also, since information about the stream format is going to be needed at the
Writer level as well, the AllocateCookie() method gets the stream
media_format.
* Fleshed out some aspects of AVFormatWriter, many TODOs are left.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32025 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Implemented some of AVCodecEncoder. Maybe video encoding already works, but
we don't know until the AVFormatWriter is more than just stubs... but I doubt
it. :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32016 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Improved Encoder API towards what we need for the get_next_encoder() variants
and the BMediaTrack API.
* Implemented the rest of MediaWriter. Still undecided what to make of
AddTrackInfo(). BMediaEncoder has that as well, which hints that this is
something the Encoder needs to support. But it could also be that this is
only possible to support in Writer.
* Wired a lot of previously unimplemented methods in BMediaFile and BMediaTrack
needed for write support. If I have not overlooked anything, only the
parameter stuff is still unimplemented now.
This is all untested, since the FFMpeg Encoder and Writer are still only stubs.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32013 a95241bf-73f2-0310-859d-f6bbb57e9c96
The AddOnManager in the media_server registers one encoder entry per
successful EncoderPlugin::RegisterNextEncoder(). This gives us a first idea
what media_format_family and input/output media_type is supported. The
mechanism may have to be extended, or the Encoder needs an API to specialize
a format further. In that case, the get_next_encoder() version that takes
optional _acceptedInput/OutputFormat needs to instantiate the plugin and
needs to ask the Encoder. But AFAIK, no app uses it like that anyway.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32005 a95241bf-73f2-0310-859d-f6bbb57e9c96
but is better than before in any case. The deinterlacing is nothing fancy,
basically, it just drops the first field... the implementation to use this
is also not as efficient as it could be, it currently allocates a temporary
frame always...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31996 a95241bf-73f2-0310-859d-f6bbb57e9c96
current libavformat API. FFmpeg is a little inconsistent in this regard. For
interlaced video, it will report a frame rate which is the field rate, but
still decode both fields into a single frame. For the time being, we reduce
the frame rate from 50.0 to 25.0 and handle interlaced video transparently
for the clients. This needs to be fixed later on...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31995 a95241bf-73f2-0310-859d-f6bbb57e9c96
need to work differently, such that supported media_formats come into play,
I will know soon when I implement some of the stuff from MediaFormats.h.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31994 a95241bf-73f2-0310-859d-f6bbb57e9c96
"AVI (Audio Video Interleave)" in the available output formats popup... :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31956 a95241bf-73f2-0310-859d-f6bbb57e9c96
AVStream does not provide it. For my test Flash Videos, I can at least get
a duration now, although seeking is pretty broken.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31616 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Seeking does not work, since the duration extraction from libavformat does
not work for this container (maybe there are ways/workarounds but I didn't
look into it).
* Automatic white space cleanup.
TODO: Add MIME type with sniffer rule.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31605 a95241bf-73f2-0310-859d-f6bbb57e9c96
audio format is now taken into account by the decoder when negociating the media output format.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31597 a95241bf-73f2-0310-859d-f6bbb57e9c96
the HAIKU_FFMPEG_DEFINES and friends to the toplevel ffmpeg Jamfile.
* Define the X86 CPU acceleration features in global Jamfile variables,
so that we can build specific source files depending on those defines
later (used for libavcodec_x86.a).
* In config.h, a whole bunch of parsers were defined off, which was the
actual reason why plain old .MPG files and also my .MTS streams with
H.264 video gave only scrambled video.
* Removed some files from the build by comparing which files are build
by a pristine FFmpeg libavcodec Makefile.
Attention: The following changes may break the GCC2 build:
* Remove Haiku specific changes from
- libavcodec/x86/cavsdsp_mmx.c
- libavcodec/x86/dsputil_mmx.c
- libavcodec/x86/h264dsp_mmx.c
I will test this next after switching my GCC. If you are impatiant, the
following changes were previously done to the pristine FFmpeg 0.5 files:
libavcodec/x86/cavsdsp_mmx.c:
* commented out line 426 to 429
libavcodec/x86/h264dsp_mmx.c
* h264_loop_filter_strength_mmx2() was commented out.
libavcodec/x86/dsputil_mmx.c
* gmc_mmx() was commented out.
* commented out line 2665 (assigning c->gmc)
* commented out line 2786 (assigning c->h264_loop_filter_strength)
However, I would now make similar changes by checking the GCC version. Also,
the libavcodec/x86/dsputil_mmx.c:2786 was still assigning the dummy
h264_loop_filter_strength_mmx2() version.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31506 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Improved Seek(). If wence is not SEEK_SET, make sure to check the current
source position and adjust it to what the stream points to. Also, return
just -1 on error since this is used for libavformat code. And don't set
the stream position to the error return value.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31504 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added debugging facility to dump the first 100 packets of a video stream
to a debug file on the Desktop.
* When needing to flush packets, avcodec_flush_buffers() is unfortunately
not reliable. For audio codecs, the work around was to close and reopen
the codec in Seek(). Do this also for video codecs. Makes H.264 more
reliable here.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31503 a95241bf-73f2-0310-859d-f6bbb57e9c96
* We can actually tell libavformat to discard packets for streams that
we are not interested in. Found this in the ffplay code. This should hopefully
avoid the efficiency impact of using one AVFormatContext per stream.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31458 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Refactored NegotiateOutputFormat() and Decode() into two separate private
methods each, one for video and one for audio.
* Keep reading chunks when video decoding, until we have got a picture. This
gets us scrambled video instead of a black picture for h264 in mpegts.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31457 a95241bf-73f2-0310-859d-f6bbb57e9c96
context has AVPrograms. I gather this feature is for container streams
that contain multiple "groups of streams" like how it would work for
satilite mpeg-ts streams with multiple TV channels in one stream. For this
to be properly supported, we should extend the BMediaFile/Track API. For
now, the AVFormatReader uses the first program, if one is there. This
was also needed to get make mpegts demuxer work, but it is not yet enabled
for other reasons.
* Read more probe data. 1024 bytes were not enough to detect "mpegts" properly
for example.
* For now, I disabled the locking in the AVFormatReader hooks themselves,
this should not be necessary, though I hope libavformat is reentrant as
long as you have your own AVFormatContext for each thread. So far everything
hints that it is the case.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31454 a95241bf-73f2-0310-859d-f6bbb57e9c96
just architecture specific flags, call them just HAIKU_FFMPEG_DEFINES.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31432 a95241bf-73f2-0310-859d-f6bbb57e9c96
how everything currently worked. (Packet peaking was only done once in Init().)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31423 a95241bf-73f2-0310-859d-f6bbb57e9c96
container formats we support. I hope I have turned on only those that don't
have an implementation already (did we support ASF already?). I mostly tested
with AVI and that works reasonably well, but I only tested raw audio so far.
However, the backend for Marcus' avi_reader is much nicer than FFmpeg, so I
think it should stay and have disabled the support for AVI in AVFormatReader.
A big disappointment is that MPG containers only give scrambled video. It may
be a problem of the AVCodecDecoder, but I am not so sure. After all, it works
fine for other container formats. If I am not mistaken, VLC also does not use
the mpeg demuxer from FFmpeg. :-\ On top of that, libavformat detects the
time_base and stream duration wrongly for one of my test MPGs.
As for the implementation: Although seeking in libavformat happens for an
individual stream, in reality, the packets for all other streams need to be
flushed (that's also what happens in the libavformat tutorials I've seen).
Since our MediaKit API allows to seek tracks indivually, this is of course
a no-go, since then all other tracks would be out of sync. My solution is to
simply open the demuxer once for each stream and then completely ignore the
packets of the respective other streams. This also works around the problem
that libavformat is unable to provide packets by stream, requiring the
API user to queue the packets that he needs not now, but later for other
streams. It also means we have to no memory copies, since we can directly
use the packet buffer until the next call to GetNextChunk().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31421 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Moved stuff from testing in Sniff() into class members.
* Added function to gfx_utils() that converts an FFmpeg pix_fmt to color_space.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31402 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The URLProtocol idea seems not to work out, so I removed that code, but
the other idea of setting up a ByteIOContext actually works, once I seek
back to the beginning of the stream after reading the initial probe buffer,
we may also offset the buffer pointer in the ByteIOContext to where we
have already read, but I am not sure of possible side effects of that.
We can now probe for the correct demuxer and detect streams.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31379 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Turn off tracing in the AVCodecDecoder which I accidentally turned on in
a previous commit.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31366 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Removed inclusion of internal.h from libavcodec.h, it's not there in the
plain FFmpeg 0.5 version of the file.
The last item fixes the GCC2 build, at least AFAICT.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31364 a95241bf-73f2-0310-859d-f6bbb57e9c96
unified the Reader and Decoder plugins and renamed the add-on to "ffmpeg".
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31358 a95241bf-73f2-0310-859d-f6bbb57e9c96
"ffmpeg" and export multiple plugin types from the same plugin (Decoder and
Reader).
* Work in progress on an libavformat based Reader plugin, does nothing yet.
* Moved config.h from libavcodec subfolder up one level, so that it's used
by libavformat as well. Adjusted libavutil/common.h accordingly.
* Turned off GPL code in config.h
* Turned off BeOS muxers in config.h
* Turned on HAVE_THREADS and HAVE_PTHREADS, although that is nowhere used
in the ffmpeg code (it appears).
* Indentation cleanup in avcodecplugin.h
I have built this with GCC4, but last night I built libavformat.a with GCC2
so I am hoping this doesn't break the GCC2 built.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31355 a95241bf-73f2-0310-859d-f6bbb57e9c96
easily: moved out of config.h some definitions that we could do
dynamically per target architecture.
NOTE: ppc, m68k and sparc optimizations are currently missing and should
be imported from ffmpeg 0.5 before we can build avcodec plugin for these
targets. Hence why it's still X86_ONLY qualified.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30185 a95241bf-73f2-0310-859d-f6bbb57e9c96
to support more than just x86. Not yet SubInclude'd, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30179 a95241bf-73f2-0310-859d-f6bbb57e9c96
build.
* Remove the APE reader from the image as it also depends on the non-working
yasm rule.
Please don't just leave the build in such a broken state. It's really annoying
when you're held up by stuff like that when you want to work on something.
Just leave changes like those disabled until you have verified that they work.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30111 a95241bf-73f2-0310-859d-f6bbb57e9c96
such that all channels are affected.
* This fixes the "setvolume" command under Haiku.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30013 a95241bf-73f2-0310-859d-f6bbb57e9c96
libavcodec ASM code to fix the GCC4 build. Tested with GCC4 on Haiku.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29557 a95241bf-73f2-0310-859d-f6bbb57e9c96
- fixed uninitialized fields in CamDeframer, it works also in Haiku now :)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29507 a95241bf-73f2-0310-859d-f6bbb57e9c96
Hopefully, I am not stepping on your toes, David! Please check these changes,
I've added some TODOs where problems may be lurking.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29312 a95241bf-73f2-0310-859d-f6bbb57e9c96
* hey media_server QUIT
* /system/servers/media_server > /boot/home/media_server.log
* listusb -v > /boot/home/listusb.log
and mail the two resulting files to ithamar AT unet DOT nl. Thanks!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29282 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Fix some minor printf()-style warnings in the debug build of usb_webcam.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29279 a95241bf-73f2-0310-859d-f6bbb57e9c96
I have received permission from Øyvind Smestad to use the part he wrote under MIT licence, but some other parts are GPL sources from Linux.
The plan is to merge the core part into usb_webcam, and use either the JPEG Translator or libjpeg to replace the GPLed jpeg decoding part.
Here is what he said:
From Øyvind Smestad (o.smestad AT gmail.com):
When it comes to licencing, the media addon part is heavily based on
the VideoProducer sample code from Be (I don't remember their exact
licensing terms, but they were quite liberal weren't they?). The
driver part is partially based on the Linux FinePix driver by Frank
Zago (http://www.zago.net/v4l2/finepix/ -
http://sourceforge.net/projects/fpix/), that is where the Linux JPEG
code came from and also where I got the device IDs. If the JPEG part
is removed I don't think there should be enough left there to break
the GPL, as the rest of the code is probably more "inspired by" than
"copied from" the Linux driver. At least I remember having to monitor
the USB traffic under Windows to get the setup commands right, and I
also think there were some articles on writing a BeOS webcam driver
and on using the USBKit that I used as references.
I hope that made it a bit more clear!
As for what I did, I'm more than happy for it to be under MIT licence.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29066 a95241bf-73f2-0310-859d-f6bbb57e9c96
build. I sure hope that this doesn't break the build for anyone else.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28992 a95241bf-73f2-0310-859d-f6bbb57e9c96
mixer's controls, so I am removing it.
If someone disagrees, this code can be added back easily.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28509 a95241bf-73f2-0310-859d-f6bbb57e9c96
