> My question is, when casting signed to unsigned, is there any possibility
> that the signal gets modified due to the 2-complementation (or are the
> samples always positive somehow) ?
Casting does not change the value of the samples at all. It's just tells the
compiler that they are somethi
It's sounds a bit like you're seeing multi-threaded decoding, in which each
decode call gets back a frame that was previously passed in as a packet, and
was decoded on another thread.
The returned frame should have an associated PTS, so it's not a problem.
Set the number of threads to 1 in yo
On Dec 6, 2013, at 4:39 PM, wm4 wrote:
> On Thu, 5 Dec 2013 10:53:37 -0800
> Bruce Wheaton wrote:
>
>> On Dec 5, 2013, at 3:41 AM, Paul B Mahol wrote:
>>
>>> On 12/5/13, Eric Beuque wrote:
>>>> How i can tell libavcodec that i want to become the own
> On Dec 6, 2013, at 0:17, Eric Beuque wrote:
>
>
>> On Thu, Dec 5, 2013 at 9:22 PM, Paul B Mahol wrote:
>> On 12/5/13, Bruce Wheaton wrote:
>> > On Dec 5, 2013, at 3:41 AM, Paul B Mahol wrote:
>> >
>> >> On 12/5/13, Eric Beuque wrote:
>
On Dec 5, 2013, at 3:41 AM, Paul B Mahol wrote:
> On 12/5/13, Eric Beuque wrote:
>> How i can tell libavcodec that i want to become the owner of the data and
>> be able to free it, to without codec context instance? I was thinking about
>> using get/release_buffer functions, but i don't know how
On Dec 1, 2013, at 2:43 AM, Adi Shavit wrote:
> Does anyone have any insights or some references I should follow regarding
> this issue?
Adi, are you aware that ffmpeg does/can employ multi-threaded decoding already?
If you set the correct number of threads by setting thread_count in your
avc
On Oct 7, 2013, at 9:34 AM, Julian Herrera (TVGenius)
wrote:
> Hi Paul and wm4,
>
> Thank you for your support. I realised I just needed to activate reference
> counting, so I set
>
> AVCodecContext->refcounted_frames = 1;
>
> before avcodec_open2() and then it worked! I do not have to copy
On Oct 17, 2013, at 10:31 AM, James Board wrote:
> >And issue is probably withing avi container as it
> >may not add every frame into index table.
> >And when seeking you never check if returned packet actually is right
> >one that you need.
> >
> >Or it could be bug in your code how you seek in
On Oct 16, 2013, at 8:56 AM, Bruce Wheaton wrote:
>
>> On Oct 16, 2013, at 8:46, Paul B Mahol wrote:
>>> The only workaround is to use intra-frame only compression, so all frames
>>> are independent. Some codecs you listed always work that way.
>>
>> f
> On Oct 16, 2013, at 8:46, Paul B Mahol wrote:
>> The only workaround is to use intra-frame only compression, so all frames
>> are independent. Some codecs you listed always work that way.
>
> ffvhuff is intra only.
I don't know that codec. I just knew it was lossless. So I guess (unless
ther
Bruce
> On Oct 16, 2013, at 6:52, James Board Does my question make sense to anyone? Or am I doing something very wrong
> with libav and seeking? Has anyone seen this behavior before when you seek to
> position N in a file, but the first few frames that get decoded are lower
> than N?
> Is
On Oct 14, 2013, at 4:46 AM, Dolevo Jay wrote:
> I have encoder and decoder application in separate projects. I use x264 to
> encode the incoming frames and use libav to decode them. If the frame has a
> specific resolution like 1366 x 768, the decode frame contains extra black
> border at the
On Oct 9, 2013, at 7:29 AM, James Board wrote:
>
> Really? The title of the mailing list is Libav-user@ffmpeg.org.
> I'm asking whether libav can be used in C++ programs, if anyone
> uses libav in C++ programs, and what I need to do in order to
> use libav in C++ programs. How can that be inapp
elligence of
the people (not me, I'm just a 'user' of ffmpeg) who made the API I'm choosing
is better than my singular, less specific experience. Every time I feel
compelled to re-invent the wheel because I know better (coff, coff), it turns
out the existing API decsions
On Oct 8, 2013, at 11:12 AM, James Board wrote:
>
> I tried exactly that with the demuxing.c example. When I try to compile
> it with the C++ compiler, I get errors. When I compile with the C compiler,
> no errors. What do I need to do to get demuxing.c to compile with the C++
> compiler in Li
On Oct 8, 2013, at 12:05 PM, James Board wrote:
> I want to create several pthreads in a C++ program (assuming you can call
> libav routines from a C++ program) that each call libav subroutines.
Well, yes, you can call C from a C++ app. You need to mark the headers as C
when you include them,
On Oct 4, 2013, at 11:43 AM, MXWendler LibAV wrote:
> Is there a reliable way to derive the line size from eg. resolution and / or
> pixel format? Like eg. PIX_FMT_YUV420P has three line entries (ycbcr), and
> the Y stride is XX and the cb/cr stride is half of that?
No, there isn't. You can re
On May 15, 2013, at 9:13 AM, Joe Flowers wrote:
> Carl and Hendrik,
>
> Thank you very much for your comments and expertise.
>
> You are right, I'm mixing up thread-safety and re-entrantcy. Sorry.
>
> With Hendrik's advice on not cancelling threads to prevent a deadlock or
> zombie-type thr
On Apr 27, 2013, at 10:44 AM, Brad O'Hearne wrote:
> On Apr 26, 2013, at 1:45 PM, Bruce Wheaton wrote:
>
>> It may be that your source of dest buffers, if not from ffmpeg, are not
>> correctly aligned.
>
> To the best of my knowledge, the source data is aligned,
On Apr 26, 2013, at 9:45 AM, Brad O'Hearne wrote:
> So for instance, say samples are derived from an outside source (such as
> capture), and channels/planes are delivered and properly structured, and code
> was not to use the av_samples_fill_arrays above, but rather set pointers
> themselves. T
On Apr 24, 2013, at 10:43 AM, Brad O'Hearne wrote:
> 2. For planar data, what exactly is the expected structure of the data array?
>
> is it:
>
> data[0] -> plane 1
> data[1] -> plane 2
>
> or is it
>
> data[0] -> plane 1
> data[0 + plane_size] -> plane 2
>
This seems quite clear in sample
Is there any info about the changes in this area? It caused some problems in my
code when the definition of PixelFormat (instead of a type/enum named
PixelFormat) seemed more invasive with other namespaces.
I undef'ed pixelformat, and used AVPixelFormat in my code. But I see there's a
switch tr
On Sep 4, 2012, at 2:42 PM, Carl Eugen Hoyos wrote:
> They were removed some time ago.
> (Those limits where never codec-related.)
>
>> in various places.
>> Where are you seeing that 8k is supported?
>
> I tested it.
Great, thank you for doing that. I'll start doing some post-HD codec testin
On Sep 4, 2012, at 10:41 AM, Carl Eugen Hoyos wrote:
> Bruce Wheaton writes:
>
>> I know most FFMPEG codecs only work up to 4096 x 4096
>
> Could you elaborate?
> (I had to search to find a codec that did not support 8k.)
Maybe my information was out of date! That would
I know most FFMPEG codecs only work up to 4096 x 4096, for various good
reasons. Is anyone aware of codecs that support greater, such as 6K or 8K?
Bruce
___
Libav-user mailing list
Libav-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/libav-user
On Aug 30, 2012, at 8:08 AM, Camera Man wrote:
> On 08/29/2012 11:53 AM, Mark Kenna wrote:
>> Can someone tell me how a conversion for live streaming is possible? Also, I
>> would be doing the file conversion dynamically in memory which means that I
>> cannot just encode a file, re-position the
> I just have no idea what's the relationship between ffmpeg and libav? It
> seems
> libav is replacing ffmpeg? Which is newer? Are ffmpeg and libav 2 different
> groups?
Touchy topic. Picked at random, here's some discussion on the situation:
http://blog.pkh.me/p/13-the-ffmpeg-libav-situatio
On May 30, 2012, at 8:02 PM, ashika umanga wrote:
>
> for(y=0;yfor(x=0;x< encoder.getVideoParams().width;x++){
>
>
>targetFrame->data0[index][(y* width)+x]=(x%255); //R
>targetFrame->data0[index][(y* width)+x+1]=0; //G
>targetFrame->data0[index][(y* width)+x+2]=0;
On May 7, 2012, at 3:05 AM, Alex Cohn wrote:
>
> Unfortunately, AVFormatContext Struct Reference
> [http://ffmpeg.org/doxygen/trunk/structAVFormatContext.html] says
> explicitly that this object can only be iformat or oformat, not both
> at the same time.
>
> As for AVStream, there is no explici
On May 6, 2012, at 12:36 PM, Alex Cohn wrote:
> > Good question. The intent is to seamlessly move from ingesting a movie and
> > viewing it to playing back. I can't find a way to access the same movie for
> > playback as it's being ingested (that would work fine too), can't tell
> > which media
On May 6, 2012, at 7:16 PM, Kalileo wrote:
>> code.
>
> Why don't you simply play the movie _before_ you encode it, when you still
> have the raw data?
I'd like to do both at once. Play the raw frames, and pass them for encoding,
then at the end, finalize the movie and switch to playback mode.
On May 6, 2012, at 11:04 AM, Alex Cohn wrote:>
> > Then I suppose the question becomes, can I use the same AVFormatContext
> > with encoders and decoders… and use the same AVStreams?
> >
> > Bruce
>
> They were never designed for such reuse; but even if you could, what kind of
> profit would you
On May 5, 2012, at 9:16 PM, Alex Cohn wrote:
> On May 6, 2012 6:28 AM, "Bruce Wheaton" wrote:
> >
> > Is it possible to open codecs for encoding, and use them to encode a
> > complete piece, then, on the fly (when the complete clip had already been
> >
Is it possible to open codecs for encoding, and use them to encode a complete
piece, then, on the fly (when the complete clip had already been encoded)
switch over and use them to decompress the same media?
I'm flexible on which codecs, although I like MP4 for being LGPL and good at
multi-threa
Are any of the movie container types supported by ffmpeg set up to allow
reading and writing at the same time? I will be feeding in frames I have
decoded elsewhere, and would like to view them and save them to a file at the
same time.
Obviously I could split the frames, and view them and save t
On Feb 5, 2012, at 8:38, Carl Eugen Hoyos
> (Or in other words: It will only affect you if you want H264 encoding
> but are not willing to buy a commercial x264 license.)
Carl, for my own information - there are also some 'less important' codecs that
are GPL only, correct?
And some scaling opt
On Nov 30, 2011, at 6:12, "Basha, Asif" wrote:
> Hi,
>
> I am facing problem while decoding H264 first Frame(I Frame) by using
> FFMPEG avcodec_decode_video() If avcodec_decode_video() called twice then
> it’s working fine. Can you please suggest me regarding this issue.
>
> Regards,
>
On Nov 16, 2011, at 1:56 AM, Carl Eugen Hoyos wrote:
> Bruce Wheaton writes:
>
>> Sorry, I can't find anywhere, but do ffplay and ffmpeg configure the audio
>> codec context at all?
>
>> Obviously, they configure resampling etc., but do they tell the codec con
On Nov 15, 2011, at 2:16 AM, Carl Eugen Hoyos wrote:
> Bruce Wheaton writes:
>
>> I have a fairly simple .mov with one track of stereo PCM 16-bit audio.
>> Quicktime has the channels tagged as left and right. When I open the file
>> with
>> libavformat & li
On Nov 15, 2011, at 1:41 PM, Carl Eugen Hoyos wrote:
> Bruce Wheaton writes:
>
>>> Does it play properly with ffplay (or MPlayer)?
>>> Can it be read by ffmpeg?
>>
>> I don't have ffplay active now, I'll enable it. FFMPEG fails as below. The
On Nov 15, 2011, at 2:16 AM, Carl Eugen Hoyos wrote:
> Bruce Wheaton writes:
>
>> I have a fairly simple .mov with one track of stereo PCM 16-bit audio.
>> Quicktime has the channels tagged as left and right. When I open the file
>> with
>> libavformat & li
I have a fairly simple .mov with one track of stereo PCM 16-bit audio.
Quicktime has the channels tagged as left and right.
When I open the file with libavformat & libavcodec, I get the 'Unimplemented
container channel layout' warning and it won't play properly (in my app).
If I re-save the aud
> PIX_FMT_YUV422P10 and PIX_FMT_YUV444P10 are 10-bit planar formats, delivered
> in 3 (or 4, with alpha) planes of 16-bit integers, in the endianness of the
> host platform (the actual pixel format has an endian postifix). The 10 least
> significant bits of each integer represent the pixel compo
> I noticed that a few codecs (DNxHD, ProRes and v210 support this pixel format
> now). That's great, but I can't find much information about it. I tried to
> trace where it's being handled in swsscale, and it seems that it's actually a
> 16-bit format, with unused bits, much like the rarely see
I noticed that a few codecs (DNxHD, ProRes and v210 support this pixel format
now). That's great, but I can't find much information about it. I tried to
trace where it's being handled in swsscale, and it seems that it's actually a
16-bit format, with unused bits, much like the rarely seen 16-bit
On May 19, 2011, at 10:15 PM, pavan kumar wrote:
> while (avpkt.size > 0) {
>
> len = avcodec_decode_video2(c, frame, &gotpicture, &avpkt);
>printf("Value of len =%d \n ",len);
>if (len > 0) {
> fprintf(stderr, "Error while decoding fra
The 10:13am GIT commit working with VDPAU and MPEG breaks on Mac, since VDPAU
isn't present.
Linker errors:
LD libavcodec/libavcodec.52.dylib
Undefined symbols:
"_ff_vdpau_mpeg_picture_complete", referenced from:
_decode_chunks in mpeg12.o
"_ff_mpeg2_vdpau_hwaccel", referenced fro
47 matches
Mail list logo
