[x264-devel] Appending an iFrame to the start of a h264 video?

Cary Fitzhugh cfitzhugh at echo360.com
Wed Jul 23 16:20:48 CEST 2008


Hello again.

So - I have the ability to edit my h264 streams - and that seems to work ok if I am careful about it.
But when i try to wrap it in an mp4 for QT to play (MP4Box or ffmpeg)  - it destroys the video.  At the edit points it 
becomes 'bubbly' and swirly.

Is it fundamentally a problem trying to put multiple different h264 streams into one?
 From all I can understand it should be perfectly acceptable to edit AVC movies this way.

ffmpeg can read these movies in no problem and export to mjpeg or what not - so I believe that they are 'valid'.
But the minute I try to put them into an MP4 container - all goes to heck.

Any ideas?  Thanks again,
Cary FitzHugh

Cary Fitzhugh wrote:
> Ok - so - for anyone else who is looking about. I'll just record my findings.
> 
> Look at the type of NAL.  If it is type 1,2,3, 4 or 5 - it is a video NAL.
> 
> Of those, the first is a non IDR type.  The second is a partition A, then B, then C type, then an IDR type.
> I don't know what B or C are, nor really what the others are.  But i haven't seen anything but non IDRs in my adventures 
> - and the nonIDR and A type have the slice_header which is what you want to look at to tell the type of the frame.
> 
> In the slice header - which is the next thing in the stream after the NAL header - there are a few things to do.
> You have to decode the first_mb_in_slice unsigned value.
> Then next is the slice type unsigned value.
> 
> Slice types are:
> 0    P
> 1    B
> 2    I
> 3    SP
> 4    SI
> 5    P
> 6    B
> 7    I
> 8    SP
> 9    SI
> 
> How to decode those values...  I know that Mp4Box and FFmpeg have code which decodes those Exp Golomb values. 
> (Interestingly they look the same, yet one says it is FFMPEG code and the other says it is MP4Box code...)
> 
> I believe the AVC specific way to decode exp golomb values is to do the following: (AVC specific b/c the k value is 0) 
> (Look at wikipedia)
> 
> count the number of 0 bits before you hit your first 1 value. Save that as N.
> Put the next N+1 bits into a variable
> Then subtract 1 from that value.
> 
> Thanks,
> Cary FitzHugh
> 
> Tomas Carnecky wrote:
>> Make sure ffmpeg is producing raw .264 files (with no headers or such). 
>> A simple check is to see if the first three of four bytes of the file 
>> are (0x00) 0x00 0x00 0x01.
>>
>> tom
>>
>> Cary Fitzhugh wrote:
>>> Thanks for the reply!
>>>
>>> I'll keep looking if you all think it is possible.
>>> I may be getting tripped up by ffmpeg adding some header information onto the front. I'm not sure.
>>>
>>> At least I have a clue that it may be possible.
>>>
>>> Thanks so much,
>>> Cary
>>>
>>> Alex Giladi wrote:
>>>> "cat movie1.264 movie2.264 > longer_movie.264 " should suffice, AFAIK.
>>>>
>>>> On Wed, Jul 9, 2008 at 12:41 PM, Cary Fitzhugh <cfitzhugh at echo360.com> wrote:
>>>>> Hello --
>>>>>
>>>>> I'm trying to figure out if there is a way to concatenate two h264 files without reencoding.
>>>>>
>>>>> I am making edits of longer h264 videos.
>>>>> In order to make sure that my video starts on an iFrame - I want to use ffmpeg to encode a single frame at the start
>>>>> time.  Then in a subsequent call - do a -vcodec copy on the rest of the edit.
>>>>>
>>>>> This provides me with 2 h264 movies.  One is 1 frame long and is an iframe.  The second movie is the rest of the edit.
>>>>>
>>>>> I do not understand the h264 codec well enough - which is why I'm writing you all.  It makes sense in my head, that if I
>>>>> were to just concatenate the raw h264 files together and wrap it I should have a valid h264 file.
>>>>>
>>>>> In my movies I do not have B frames, just P and I frames.  My understanding is that P frames are only moving forward.
>>>>> So prepending that initial i frame onto the front of the edit should work fine.
>>>>>
>>>>> I tried this, and when I combined the two it got very swirly and messed up on vlc.
>>>>>
>>>>> ANy ideas if this is possible?  I would really like to do this no matter how convoluted I need to get.  When I'm editing
>>>>> 1 - 4 hour movies all the time I would rather not wait 20% of real time to make an edit - just for that first iframe.
>>>>>
>>>>> Thanks for any insight into this.
>>>>>
>>>>> Cary FitzHugh
>>>>> _______________________________________________
>>>>> x264-devel mailing list
>>>>> x264-devel at videolan.org
>>>>> http://mailman.videolan.org/listinfo/x264-devel
>>>>>
>>>> _______________________________________________
>>>> x264-devel mailing list
>>>> x264-devel at videolan.org
>>>> http://mailman.videolan.org/listinfo/x264-devel
>>>>
>>>>
>>> _______________________________________________
>>> x264-devel mailing list
>>> x264-devel at videolan.org
>>> http://mailman.videolan.org/listinfo/x264-devel
>>>
>> _______________________________________________
>> x264-devel mailing list
>> x264-devel at videolan.org
>> http://mailman.videolan.org/listinfo/x264-devel
>>
>>
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel
> 
> 


More information about the x264-devel mailing list