André Anjos writes:
> [libmp3lame0x7fa7d201f200] Channel layout not specified
> Output #0, avi, to 'test.avi':
> Stream #0:0: Video: ffv1, yuv420p, 352x288, q=2-31,
> 400 kb/s, 90k tbn, 25 tbc
> Stream #0:1: Audio: mp3 (libmp3lame), 44100 Hz,
> 2 channels, fltp, 64 kb/s
> Error enco
Hello,
I'm using a MacPorts build of ffmpeg 2.0.2. It passes most of our tests,
except the one using the FFV1 codec. This seems independent of the file
format chosen.
How to reproduce the problem:
1) Download the muxing example from the ffmpeg doxygen documentation (
http://ffmpeg.org/doxygen/2.
Robert Krüger writes:
> I was interested to know how you found out that
> ffmpeg "thinks" the 28th frame is a random access
> point
I concatenated the second until the 29th frame of the
input sample and tested decoding with current FFmpeg.
I also wanted to test with the reference decoder
(tha
Hello all,
I am writing a an application that encodes incoming video in H.264 using
libavcodec and libx264. However, I noticed that the output data was much
larger than I expected. When I examined the output, I discovered that the
encoder was only producing I- and P-frames and never producing
On Mon, Oct 21, 2013 at 6:38 PM, Carl Eugen Hoyos wrote:
> Robert Krüger writes:
>
>> Btw, is it intentional that you don't answer questions
>> I ask in my emails?
>
> Please understand that you know much more than I do about
> H.264 so I simply cannot answer most of your questions.
No, I don't
Robert Krüger writes:
> >> > Even better. Which commit are you talking about?
> >
> > Iirc, fixed ticket with keyword "h264".
>
> You mean 2738?
I believe this is the one I meant.
Carl Eugen
___
Libav-user mailing list
Libav-user@ffmpeg.org
http://f
Robert Krüger writes:
> Btw, is it intentional that you don't answer questions
> I ask in my emails?
Please understand that you know much more than I do about
H.264 so I simply cannot answer most of your questions.
http://wiki.multimedia.cx/index.php?title=Mirror contains
a copy of an old H.
On Mon, Oct 21, 2013 at 5:46 PM, Carl Eugen Hoyos wrote:
> Robert Krüger writes:
>
>> Since only P- and I-slices are parsed (I can see that
>> in the debug output), I would indeed expect every
>> I-frame (meaning any frame only consisting of one
>> I-slice in the stream) to be a valid access poin
Robert Krüger writes:
> Since only P- and I-slices are parsed (I can see that
> in the debug output), I would indeed expect every
> I-frame (meaning any frame only consisting of one
> I-slice in the stream) to be a valid access point
So you mean a P-frame after an I-frame is not allowed to
r
On Mon, Oct 21, 2013 at 4:21 PM, Carl Eugen Hoyos wrote:
> Robert Krüger writes:
>
>> If my debug output is correct, both contain no
>> B-slices/frames (I just noticed that) but they
>> do contain I-slices/frames. If I am not missing
>> something, those I-Frames should be valid random
>> access p
Robert Krüger writes:
> If my debug output is correct, both contain no
> B-slices/frames (I just noticed that) but they
> do contain I-slices/frames. If I am not missing
> something, those I-Frames should be valid random
> access points then.
Do you mean you debugged the sample (with a strea
On Mon, Oct 21, 2013 at 1:04 PM, Carl Eugen Hoyos wrote:
> Robert Krüger writes:
>
>> I'll be more than happy to do that. How do you want
>> me to do it? Open a ticket (if so, what would be an
>> appropriate topic/title in your opinion?) or by
>> some other means?
>
> Whatever seems appropriate a
Robert Krüger writes:
> I'll be more than happy to do that. How do you want
> me to do it? Open a ticket (if so, what would be an
> appropriate topic/title in your opinion?) or by
> some other means?
Whatever seems appropriate and simple to you, as you
know there is a ftp/http upload site, y
On Mon, Oct 21, 2013 at 12:13 PM, Carl Eugen Hoyos wrote:
> Robert Krüger writes:
>
>> In case of the files I am talking about here, there are no recovery
>> point SEIs after the first frame so libavformat/avcodec is probably
>> doing everything correctly, too. Since I think I know that these
>>
Hi,
thanks for your help.
Your function above, if i understood correctly, read from raw file, put
data into video_buf and at the end returned the number of bytes read. Now i
want to encode, so i must to pass raw data to avcodec_encode_video2
function, that takes input raw video data from frame. S
Robert Krüger writes:
> In case of the files I am talking about here, there are no recovery
> point SEIs after the first frame so libavformat/avcodec is probably
> doing everything correctly, too. Since I think I know that these
> streams in fact do have random access points, I will probably have
On Sun, Oct 20, 2013 at 2:44 PM, Carl Eugen Hoyos wrote:
> Robert Krüger writes:
>
>> So are you saying that AVPacket.key_frame should be
>> set to 1 for recovery points in H.264?
>
> No, on the contrary, I don't think this would "work"
> (depending on the definition of work) in the sense
> that
17 matches
Mail list logo