Thx Mike, that was a good advise, as I didn't understand some parts correctly. But finally I was able to decode the first Keyframe (using SPS, PPS and IDR each separated with a 32bit startcode). Thus Huy and Alex were right. My problem was deep in my code. It didn't add the prefix at all and the frame I received from the server were not complete nalus (fragmented) and I had to combine them by comparing PTS-values. At least there is light at the end of the tunnel! :)
Cheers Sven I will write a howto when I am finished with my thesis. 2010/9/25 Mike Scheutzow <[email protected]>: > Sven Wasmer wrote: >> >> Hello again! >> >> Well, the parser didn't work so far. But I still have a question: >> >> When I deliver let's say four slices of a non-idr-frame to the >> decoder: what about the startcodes? >> - Prepending 0x000001 to the whole package? >> -> (0x000001 + SSSS) >> - Prepending 0x000001 to each Slice, but concantenate those four >> slices and send them to decoder? >> -> 0x000001 S + 0x000001 S +0x000001 S +0x000001 S >> > > The FFmpeg h264 parser and h264 decoder expect to receive an input bitstream > in H.264 Annex B format. If you feed a different format in, it is not going > to work. Simply appending 00 00 00 01 to the front of a bitstream is not > likely to succeed, and this is not the proper way to convert a random stream > into Annex B format. > > Annex B is defined in the ITU H.264 specification document. It will save you > much frustration if you google for this document, download it, and read > Annex B. Annex B is very short and not to difficult to understand. It will > answer these questions which you ask. > > Mike Scheutzow > > > _______________________________________________ > libav-user mailing list > [email protected] > https://lists.mplayerhq.hu/mailman/listinfo/libav-user > _______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
