[FFmpeg-devel] h264_annexbtomp4 filter ideas, was: Collection of patches

[Michael Niedermayer]

wOn Thu, Apr 24, 2008 at 09:10:50AM +0200, Thorsten Jordan wrote:
> Thorsten Jordan schrieb:
> > Michael Niedermayer schrieb:
> >> On Wed, Apr 23, 2008 at 09:15:40AM +0200, Thorsten Jordan wrote:
> >> [...]
> > 
> >>> work. Maybe it has been fixed differently meanwhile, but i can't
> >>> imaginge how.
> >> Your patch generates invalid/broken h264. The current code generates broken
> >> ones too but they dont work which prevents them from spreading. Thus your
> >> patch clearly makes it worse, the issue is not fixed it just appears that it
> >> is. The spliting API in ffmpeg has to be changed to allow spliting random
> >> subsets of the headers out. Please see the mailing list where i described
> >> this more precissely IIRC.
> > ah now i see your point. The splitter should thus extract the SPS and
> > PPS only and put it in extradata, and leave the rest of the stream as it
> > is (including the SEI NALs). If there are NALs other than SPS/PPS
> > inside, it would be incompatible to MP4 extradata format, as it expects
> > only SPS and PPS units.
> > So if there is "SPS - SEI - PPS - other/rest..." in the stream, extract
> > "SPS - PPS" to extra data, and keep "SEI - other/rest..." in the stream
> > 
> > In the discussion about that problem on this list, you said that the two
> > SEI NALs in my example shouldnt be part of global headers. I checked the
> > h264 spec and there are 22 types of SEIs. None of them sound like they
> > are SPS/PPS related.
> > 
> > Which brings up the question if there should be never SEI units in
> > global headers. I found nothing near the SPS/PPS description that
> > mentions SEI, so they are not used as header extension?
> 
> If one would solve this by writing a h264_annexbtomp4 bitstream filter,
> there are some issues:

The problem is the parser_split() API not h264_annexbtomp4. The world
is not just .mp4 and .h264, there are other containers needing the headers
seperated but in annex B format. 
Besides this the decoder needs the headers as well, they can occur later
then the first IDR frame the common code will read ahead until the split
function has filled them in. Your suggested hack of doing this in 
h264_annexbtomp4 will break decoding of such streams.


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
-------------- 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/20080424/d73e367c/attachment.pgp>