Kalileo writes:
> That's how I do it, and it works for me. Wait for the first I-frame
Don't forget that valid H264 streams do not necessarily contain I frames.
(I don't know of such a sample.)
Carl Eugen
___
Libav-user mailing list
Libav-user@ffmpeg
On May 4, 2012, at 00:16 , jettoblack wrote:
>
> Kalileo wrote
>>
>> On Apr 30, 2012, at 23:53 , jettoblack wrote:
>>
>>> On Mon, Apr 30, 2012 at 2:51 AM, Kalileo [via libav-users] <
>>> ml-node+s943685n4597541h88@.nabble> wrote:
>>>
The decoder gives you the (decoded) pictures in
Kalileo wrote
>
> On Apr 30, 2012, at 23:53 , jettoblack wrote:
>
>> On Mon, Apr 30, 2012 at 2:51 AM, Kalileo [via libav-users] <
>> ml-node+s943685n4597541h88@.nabble> wrote:
>>
>>>
>>> The decoder gives you the (decoded) pictures in the correct order.
>>>
>>>
>> That's what I expected, and
On Apr 30, 2012, at 23:53 , jettoblack wrote:
> On Mon, Apr 30, 2012 at 2:51 AM, Kalileo [via libav-users] <
> ml-node+s943685n4597541...@n4.nabble.com> wrote:
>
>>
>> The decoder gives you the (decoded) pictures in the correct order.
>>
>>
> That's what I expected, and it does for MPEG-2 cod
Dear topicstarter.
You print the pts timestamps of demuxed packets. It is correct that
they are not sorted by pts. They are ordered by dts, the Decoding
Timestamp. They are in the order for being decoded. You should look at
pts of resulting frames (actually i use AVFrame.pkt_pts, as i see in
my app
jettoblack writes:
> When it contains H.264 video codec, the pts and
> incremental order from the demuxer are definitely not in
> picture display order. coded_picture_number is giving the
> closest result but it is wrong on approx. every 150th
> frame (key frames?).
Are you using the parser?
On Tue, May 1, 2012 at 2:20 AM, Carl Eugen Hoyos [via libav-users] <
ml-node+s943685n4600239...@n4.nabble.com> wrote:
> jettoblack writes:
>
> > I tried that and for H.264 it's definitely wrong if I use the frames
> > in-order from the demuxer. It does work fine for MPEG-2 video.
> >
> > Should
jettoblack writes:
> I tried that and for H.264 it's definitely wrong if I use the frames
> in-order from the demuxer. It does work fine for MPEG-2 video.
>
> Should I file a bug report?
Is the problem reproducible with ffmpeg -i input -qscale 2 out.avi
or ffplay file ?
Carl Eugen
_
On Mon, Apr 30, 2012 at 2:51 AM, Kalileo [via libav-users] <
ml-node+s943685n4597541...@n4.nabble.com> wrote:
>
> The decoder gives you the (decoded) pictures in the correct order.
>
>
That's what I expected, and it does for MPEG-2 codec video, but not for
H.264 codec within a MPEG-2 transport str
The decoder gives you the (decoded) pictures in the correct order.
The PTS value _should_ reflect that order.
I would try to attach the metadata in the order as you get it from the demuxer
with the pictures as you get them out of the decoder.
Basically, it is exactly the same syncing you have
Hello,
I have a question about determining the display order of picture frames when
demuxing a MPEG-2 transport stream that contains either MPEG-2 video or
H.264 video.
I'm using ffmpeg git head latest as of the past couple days. My code uses
libavformat to demux the stream, add some metadata whi
11 matches
Mail list logo
