[FFmpeg-devel] RTP mark bit not passed to parse_packet
Michael Niedermayer
michaelni
Thu Jan 15 15:37:10 CET 2009
On Thu, Jan 15, 2009 at 03:06:48PM +0100, Alexandre FERRIEUX - FT/RD/SIRP/ASF/SOFTL wrote:
> Luca Abeni wrote:
> >
> > - bitstream with 0000 but no payload header
> >
> > I do not know the H.263 bitstream format, but if I understand well the
> > third option looks the correct one. Basically, you should return a
> > valid H.263 bitstream (removing the RTP payload header and adding back
> > the parts that have been removed during the RTP packetisation).
> >
> >
> >> (and similar question for follow-ons).
> >
> > In the follow-on the RTP packetiser does not remove any byte from the
> > bitstream, right? So, I think you should just remove the two bytes
> > of the payload header without adding anything to the bitstream.
> >
>
>
> OK I followed your advice, and it partly works :)
>
> "Partly", because passing the raw bitstream as is (ie one AV packet per
> RTP packet, after taking care of the headers as specified above), yields
> complaints from the decoder (Bad picture start code...header damaged).
>
> So I suspected the decoder wanted whole pictures, by symmetry with what
no, if AVSTREAM_PARSE_FULL is set a AVParser will be used to pack and
split things.
You can simply test this, just write the bitstream by simply concatenation
into a file with fwrite() ...
if it cannot be played back without similar errors then most likely it is
not a valid h263 stream and you forgot something (like to fix up the first
or last few bits that IIRC H263 RTP shuffles around)
That of course doesnt mean that i suggest to not build complete frames
if doing so has some advanatge ...
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090115/1cee2246/attachment.pgp>
More information about the ffmpeg-devel
mailing list