[Ffmpeg-devel] h264 decoder/ts-streams
Mon Nov 6 20:23:54 CET 2006
Am Samstag, 4. November 2006 19:05 schrieb Derk-Jan Hartman:
> On 3-nov-2006, at 18:04, Julian Scheel wrote:
> > Hi
> > Am Freitag, 3. November 2006 17:57 schrieb Nico Sabbi:
> >> no, demuxers doesn't have to do this.
> >> Use the stream_type in the pmt to determine the type of the video
> >> stream
> >> and let the decoder to the rest (it will search the right syncword)
> > I thought this is what xine does normally and what does not work
> > with xines
> > current implementation.
> >> as above, this is decoders' job; besides, in h264 0x000003 sequences
> >> have to unescaped
> > hmm, ok. But why does VLC do that?
> Because early on, the decoder/parser in libavcodec did NOT do that,
> but crash instead.
> As a matter of fact, in case the first nal is not a SPS/PPS pair, it
> still tends to crash regularly atm. (no i don't have samples. this is
> just by experience watching live TS streams).
> Also, in VLC not everything by definition goes to a decoder.
> Sometimes the data is just repacked for one or more other
> destinations. Therefore all h264 data will be packed internally to
> the startcode prefixed version, and be later reprocessed to fit best
> it's final destination streams.
Actually I just figured out it's been a very simple error in xines ffmpeg
plugin, that awaited the demuxer to signal when a frame is completed,
otherwise xine won't pass the data to the decoder.
Now I get something but still not what I want, I get errors like this:
[h264 @ 0xb76043a8]error while decoding MB 95 8, bytestream (-3)
[h264 @ 0xb76043a8]concealing 7154 DC, 7154 AC, 7154 MV errors
[h264 @ 0xb76043a8]error while decoding MB 99 10, bytestream (-6)
[h264 @ 0xb76043a8]concealing 8110 DC, 8110 AC, 8110 MV errors
all the time and the output is garbled.
Any ideas about this?
More information about the ffmpeg-devel