I'm not sure exactly what you mean, but yes as near as I can tell it
only freezes after packet loss. It was hard to tell when it was
freezing because there wasn't a lot of motion in the video but I'm
going to play with it some more today and try to identify more solid
patterns.
On Wed, Jun 27, 201
On Thu, Jun 28, 2012 at 4:17 AM, Michael Bradshaw
wrote:
>
> On Wed, Jun 27, 2012 at 6:26 PM, Tim Pitman wrote:
> > Interesting. However, I'm using x264 with --intra-refresh and --tune
> > zerolatency (no b frames).
>
> Sorry, I missed that part.
At any rate, it seems that in some cases of corru
On Wed, Jun 27, 2012 at 6:26 PM, Tim Pitman wrote:
> Interesting. However, I'm using x264 with --intra-refresh and --tune
> zerolatency (no b frames).
Sorry, I missed that part.
___
Libav-user mailing list
Libav-user@ffmpeg.org
http://ffmpeg.org/mailman
Interesting. However, I'm using x264 with --intra-refresh and --tune
zerolatency (no b frames).
On Wed, Jun 27, 2012 at 5:13 PM, Michael Bradshaw
wrote:
> On Wed, Jun 27, 2012 at 5:58 PM, Tim Pitman wrote:
>> Alrighty,
>>
>> I was relying on the return value from avcodec_decode_video2.
>> Basica
On Wed, Jun 27, 2012 at 5:58 PM, Tim Pitman wrote:
> Alrighty,
>
> I was relying on the return value from avcodec_decode_video2.
> Basically I assumed that if it was > 0 then the picture was valid.
> However, I was curious about what got_picture was for so if changed:
>
> if (ret > 0)
>
> to
>
> i
Alrighty,
I was relying on the return value from avcodec_decode_video2.
Basically I assumed that if it was > 0 then the picture was valid.
However, I was curious about what got_picture was for so if changed:
if (ret > 0)
to
if (ret > 0 && got_picture)
It no longer crashes, but instead seems to
After continued debugging I've narrowed things down somewhat. after
getting a picture from avcodec_decode_video2, I pass the data from the
picture to glTexImage2D, which is what
seems to be crashing. When I backtrace with gdb it says the the
address stored in picture->data[0]
is out of bounds. So I
After using gdb to run a backtrace it looks like my problem may be in
my OpenGL rendering. Sorry about that.
However, I still have one general question: When it comes to error
detection in situations like this, is dropping corrupted data at the
NALU level a good way to go, or is there a better way
Ok, I did some more testing, and the problem is not reproducible with
either ffmpeg or ffplay. I created a dump of the corrupted video
stream. When I play it back through my player it crashes but ffplay
just throws some new errors and then stops and the end of the video.
Any ideas?
On Tue, Jun 26
Tim Pitman writes:
> There are lots of errors but mostly they just result in
> artifacts, which is exactly what I want to happen. However,
> when the channel is bad libav segfaults with:
>
> mmco: unref short failure
(Crashes are always important bugs)
Can you reproduce the bug with ffmpeg (in
Sorry I forgot to give my setup:
Ubuntu Linux 10.04
ffmpeg version git-2012-05-19-31dfe20
built on May 18 2012 18:08:16 with gcc 4.4.3
On the encoder side:
ffmpeg from webcam:
ffmpeg \
-y \
-f \
v4l2 \
-video_size 640x480 \
-r 25 \
-i /dev/video0 \
-bufsize 50 \
-f yuv4mpegpipe
I'm experimenting with transmitting h264 over a lossy channel. On the
receiver side I have a very simple libav/opengl video player that
takes the stream and feeds it to avcodec_decode_video2 one NALU at a
time. There are lots of errors but mostly they just result in
artifacts, which is exactly what
12 matches
Mail list logo
