[Ffmpeg-devel] Re: [PATCH] PKT_FLAG_B
Michael Niedermayer
michaelni
Tue Aug 8 22:58:42 CEST 2006
Hi
On Tue, Aug 08, 2006 at 08:16:04PM +0200, Baptiste Coudurier wrote:
> Hi
>
> Michael Niedermayer wrote:
> > [...]
> >
> > no it depends on the container, mpeg in avi, nut, mov, ... will not
> > be parsed
> >
> >> Also assuming b frame regarding pts/dts difference is not exact,
> >
> > elaborate / bugreport
> > and i prefer to fix a bug instead of changing the AVPacket or AVParser
> > API to workaround it
> >
>
> Im sending a sample, Atm test is wrong for containers that does not have
> pts (avi), and anyway genpts does not generate correct pts for streams
> with B frames in avi. Parser detects correctly that frame is a B one.
>
> Let's see:
> ffmpeg -i <file.mpg> -vcodec h264 -bf 2 test.avi
knowledge of frame types of h.264 is not enough to calculate pts/ctts
so your B_TYPE flag wont help, for example:
IPBBB
dts: 01234
pts: 15234
or maybe
IPBBB
dts: 01234
pts: 26435
or ...
[...]
> >> and
> >> has_b_frames is not set when stream copying.
> >
> > the parser should set it, if it does not thats a bug which you can fix if
> > you like, alternatively you can assume it to be always 1
> >
>
> Parser depends on container, no ?
well it does ...
> Should demuxer set has_b_frame ?
if it has enough knowledge about the video then why not
> What about always invoking parser when stream copying ?
no
>
> Well assuming oftenly lead me to problems when reviewing, and when
> interpreting, so I would better stop assuming anything.
>
> IMHO If has_b_frames is 0 then stream does not contain b frames.
yes if has_b_frames has been set by parser/demuxer/decoder
>
> >> [...]
> >>
> >> Players (broadcast servers) does not behave correctly if B and P values
> >> are 0, random will be just wrong.
> >
> > elaborate, which broadcast server does what? the spec clearly says
> > "These values are provided for information purposes only."
>
> Grass Valley M Series. During import it will simply reject files with B
> and P > 0 since M Series cannot decode them for example. Unfortunately
> broadcast servers are not as robust as our beloved ffmpeg/mplayer and
> almost always rely on formats flags/infos/metadatas whatever.
>
> If you fake the number, it will be ingested and will crash the server
> when trying to play. Same goes for Closed gop flag btw. That's the next
> thing I need to figure out and detect.
well, then iam ok with trying to set the p/b count values to something
approximately correct ...
[...]
>
> >>> and the media field number should be set to dts and time line field
> >>> number to pts, not a random +=2 every frame variable
> >> That is right. media field number is actually dts,
> >
> > good so we agree
> >
> >
> >> computed correctly
> >> internally
> >
> > no your calculation is wrong, try a telecined mpeg
>
> Humm you mean MPEG 1/2 field stored right ? If so then yes it is wrong.
no i mean mpeg with some frame durations of 1.5 (that would require you
to add 3 instead of 2, strictly its interlaced so the even rules in the
spec wont apply
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is
More information about the ffmpeg-devel
mailing list