[Ffmpeg-devel] Re: [PATCH] PKT_FLAG_B
Tue Aug 8 22:58:42 CEST 2006
On Tue, Aug 08, 2006 at 08:16:04PM +0200, Baptiste Coudurier wrote:
> 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:
> >> 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 ?
> 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