New tool to change SAR in H264 bitstream

[roozhou]

I write a bitstream filter for ffmpeg. It can modify sps in H264 bitstream. So far it can change sar, fps, crop information, level, ref frames, cfr/vfr flag, fullrange flag, colorprim, transfer and colormatrix. Since the length of bitstream may be changed, I cannot make an in-place modifier.

ffmpeg git 29946
Download from sf (http://sourceforge.net/projects/direct264/files/Related%20Programs/ffmpeg%20%28demuxer_muxer%20only%29/ffmpeg_git_31792.7z/download) (win32 only)

Patches can be found on svn (https://direct264.svn.sourceforge.net/svnroot/direct264/Patches).

Note this is a demuxer/muxer only ffmpeg build.

cmdline:

ffmpeg -i infile -vcodec copy -acodec copy -vbsf h264_changesps=arg1[/arg2[/arg3]] outfile

args can be:
sar=x:y ---- Set sar to x:y, 0:0 will remove sar info
fps=x:y ---- Set fps to x/y in cfr mode or set timebase to y/x in vfr mode
level=x ---- Set level to x. (e.g. 30 for L3.0, 41 for L4.1)
crop=x:y ---- Crop x pixels from right and y pixels from bottom (e.g. 1920x1080 should use crop=0:8)
ref=x ---- Set number of reference frames to x
cfr ---- Set fps mode to cfr
vfr ---- Set fps mode to vfr
fullrange ---- Use full range (0~255)
limitedrange ---- Use limited range (16~235)

colorprim=x ---- Set color primary to x (integer)
1="bt709", 2="undef", 4="bt470m", 5="bt470bg", 6="smpte170m", 7="smpte240m", 8="film"

transfer=x ---- Set transfer to x (integer)
1="bt709", 2="undef", 4="bt470m", 5="bt470bg", 6="smpte170m", 7="smpte240m", 8="linear", 9="log100", 10="log316"

colormatrix=x ---- Set color matrix to x (integer)
0="GBR", 1="bt709", 2="undef", 4="fcc", 5="bt470bg", 6="smpte170m", 7="smpte240m", 8="YCgCo"

removesei ---- Remove SEI from bitstream. This can be used to remove user data and HRD timing info.
removeaud ---- Remove access unit delimiters, which is useless outside BD player.
removedupheader ---- Remove duplicated sps/pps. In some AnnexB bitstreams sps/pps appear in every I frame. We can safely remove them.

multiple args should be separated by /

Output format is determined by extension.
Supported input and output containers:
ts,mp4,mkv,flv --> mp4,mkv,flv
ts,mp4,mkv,flv --> raw,avi(with -vbsf h264_mp4toannexb)
raw,avi --> raw,avi

It also supports remuxing aac from adts/rm/mp4/mkv/avi to adts/mp4/mkv/avi, and you don't need -absf aac_adts2asc.

Two optional args are added to h264_mp4toannexb:
norepeatheader ---- Write sps/pps only in the first frame
avihack ---- Hack on nal start code, saving ~1 byte per frame on avi. It has no effect on raw output. Avihack implies norepeatheader

A new option -muxerfps is added to ffmpeg. Use this to set container fps for avi or default duration for mkv. This is useful for vfr video (e.g. 120000/1001 for 24/30/60 fps mixed content) or mp4/mkv/flv -> avi muxing.

Example:
convert avc in mkv to raw:
ffmpeg -i input.mkv -vcodec copy -an -vbsf h264_mp4toannexb=norepeatheader output.h264

convert avc in mp4 to avi, set container fps to 29.97:
ffmpeg -i input.mp4 -vcodec copy -acodec copy -vbsf h264_mp4toannexb=avihack -muxerfps 30000/1001 -vtag H264 output.avi

Another new option -bom can be used to add BOM to extracted text files(e.g. ass subtitles).

Example:
extract ass subtitle from mkv
ffmpeg -i input.mkv -vn -an -scodec copy -bom utf-8 output.ass

[Lam3rD]

Great, thanks a lot for this. It makes things a lot simpler

edit: about crop - why 2 and not all 4 values - left/top/right/bottom ?

[roozhou]

Because ffmpeg does not support left & top crop.

[Keiyakusha]

Is there other restrictions for crop? For 1280x720 mkv it crashes for me with crop=640:360 or crop=16:16. And in some cases when it crashes after muxing, result is unplayable...

[nurbs]

Maybe it's only supposed to crop the padding in a non mod16 video. So when you have 1920x1080 it's actually 1920x1088 with 8 pixels cropped at the bottom.

[elguaxo]

Thanks.

[b66pak]

@roozhou thanks a lot...i was waiting for this...
_

[Blue_MiSfit]

Fantastic! I've had to use a hideously slow in-house developed perl script for tasks like this. Hopefully a real application will do this more quickly :)

~MiSfit

[b66pak]

some testing:

mkv input with wrong fps

ffmpeg -i sample.mkv -vcodec copy -an -vbsf h264_changesps=fps=24000:1001 -t 20 sample.mp4


the log

F:\1>ffmpeg -i sample.mkv -vcodec copy -an -vbsf h264_changesps=fps=24000:1001 -t 20 sample.mp4
FFmpeg version SVN-r21473, Copyright (c) 2000-2010 Fabrice Bellard, et al.
built on Jan 28 2010 00:30:17 with gcc 4.4.1
configuration:
libavutil 50. 7. 0 / 50. 7. 0
libavcodec 52.48. 0 / 52.48. 0
libavformat 52.47. 0 / 52.47. 0
libavdevice 52. 2. 0 / 52. 2. 0
libswscale 0. 9. 0 / 0. 9. 0
[matroska @ 0x3ecd10]MAX_READ_SIZE:5000000 reached
[matroska @ 0x3ecd10]Estimating duration from bitrate, this may be inaccurate

Seems stream 0 codec frame rate differs from container frame rate: 47.95 (5000000/104271) -> 23.98 (5000000/208542)
Input #0, matroska, from 'sample.mkv':
Duration: 01:24:02.51, start: 0.000000, bitrate: N/A
Stream #0.0(eng): Video: h264, yuv420p, 1280x720, PAR 1:1 DAR 16:9, 47.62 fps, 23.98 tbr, 1k tbn, 47.95 tbc
Stream #0.1: Audio: 0x0000, 48000 Hz, 6 channels
Output #0, mp4, to 'sample.mp4':
Stream #0.0(eng): Video: 0x0021, yuv420p, 1280x720 [PAR 1:1 DAR 16:9], q=2-31, 24k tbn, 23.98 tbc
Stream mapping:
Stream #0.0 -> #0.0
Press [q] to stop encoding
frame= 480 fps= 0 q=-1.0 Lsize= 16803kB time=19.94 bitrate=6904.5kbps
video:16794kB audio:0kB global headers:0kB muxing overhead 0.056911%

the output mp4 is 24000/1001 fps and play OK...



raw input (previous mkv demuxed to raw) with wrong fps

ffmpeg -i sample.h264 -vcodec copy -an -vbsf h264_changesps=fps=24000:1001 -t 20 sample.mp4


the log

F:\1>ffmpeg -i sample.h264 -vcodec copy -an -vbsf h264_changesps=fps=24000:1001 -t 20 sample.mp4
FFmpeg version SVN-r21473, Copyright (c) 2000-2010 Fabrice Bellard, et al.
built on Jan 28 2010 00:30:17 with gcc 4.4.1
configuration:
libavutil 50. 7. 0 / 50. 7. 0
libavcodec 52.48. 0 / 52.48. 0
libavformat 52.47. 0 / 52.47. 0
libavdevice 52. 2. 0 / 52. 2. 0
libswscale 0. 9. 0 / 0. 9. 0
[h264 @ 0x3ecd10]max_analyze_duration reached
[h264 @ 0x3ecd10]Estimating duration from bitrate, this may be inaccurate

Seems stream 0 codec frame rate differs from container frame rate: 47.95 (959/20) -> 23.98 (959/40)
Input #0, h264, from 'sample.h264':
Duration: N/A, bitrate: N/A
Stream #0.0: Video: h264, yuv420p, 1280x720, 23.98 fps, 23.98 tbr, 1200k tbn, 47.95 tbc
Output #0, mp4, to 'sample.mp4':
Stream #0.0: Video: 0x0021, yuv420p, 1280x720, q=2-31, 24k tbn, 23.98 tbc
Stream mapping:
Stream #0.0 -> #0.0
Press [q] to stop encoding
[mp4 @ 0xa20050]pts has no value
frame= 480 fps= 0 q=-1.0 Lsize= 16802kB time=20.02 bitrate=6874.8kbps
video:16796kB audio:0kB global headers:0kB muxing overhead 0.031623%

the output mp4 is 24000/1001 fps but is not playing...
_

[Blue_MiSfit]

Can output to elementary stream be added? It doesn't look like this is supported yet..

~MiSfit

[b66pak]

also the .mp4 output no longer play in QT (is opened as audio only)...
_

[roozhou]

also the .mp4 output no longer play in QT (is opened as audio only)...
_
I set the display width/height of video track in mp4 to 0/0 and hope the player always ignore this and take width/height*sar in bitstream. Unfortunately QT fails to do so. I will revert this hack in next version.

So the width/height in mp4 container will remain unchanged until you specify "-aspect x" in ffmpeg cmdline, where x is the DAR of video in decimal.

[J_Darnley]

So the width/height in mp4 container will remain unchanged until you specify "-aspect x" in ffmpeg cmdline, where x is the DAR of video in decimal.

FYI, ffmpeg also supports a fraction or ratio as the argument for -aspect

[roozhou]

New build available.

@Keiyakusha
Crop values should fall between 0~15.

@b66pak
Currently ffmpeg does not support remuxing raw h264 stream.

@J_Darnley
"-aspect 16:9" is supported but "-aspect 16/9" will be recognized as "-aspect 16".

[J_Darnley]

@J_Darnley
"-aspect 16:9" is supported but "-aspect 16/9" will be recognized as "-aspect 16".
Oh yes, my bad. I didn't read the output too closely.

[b66pak]

@roozhou thanks a lot...
_

[b66pak]

ffmpeg -i sample.mkv -vcodec copy -an -t 20 sample.mp4

don't work anymore (infinite loop?)
_

[roozhou]

ffmpeg -i sample.mkv -vcodec copy -an -t 20 sample.mp4

don't work anymore (infinite loop?)
_
It's a regression in ffmpeg. -t and -ss seems not to work in recent build. See this thread (http://roundup.ffmpeg.org/roundup/ffmpeg/issue1728).

I will release a new build as soon as it is fixed.

[popper]

hi roozhou.

is there any chance you might also make it capable of changing the SPS to lower Refs ?

care of DS way back in 24th December 2007, http://forum.doom9.org/archive/index.php/t-133070.html
posted some Annex B data
"@0 SPS: profile_idc 01001101 ( 77)
@8 SPS: constrained_set0_flag 0 ( 0)
@9 SPS: constrained_set1_flag 1 ( 1)
@10 SPS: constrained_set2_flag 0 ( 0)
@11 SPS: constrained_set3_flag 0 ( 0)
@12 SPS: reserved_zero_4bits 0000 ( 0)
@16 SPS: level_idc 00101000 ( 40)
@24 SPS: seq_parameter_set_id 1 ( 0)
@25 SPS: log2_max_frame_num_minus4 0001001 ( 8)
@32 SPS: pic_order_cnt_type 1 ( 0)
@33 SPS: log2_max_pic_order_cnt_lsb_minus4 00110 ( 5)
@38 SPS: num_ref_frames 011 ( 2)
@41 SPS: gaps_in_frame_num_value_allowed_flag 0 ( 0)
@42 SPS: pic_width_in_mbs_minus1 0000001111000 (119)
@55 SPS: pic_height_in_map_units_minus1 00000100010 ( 33)
@66 SPS: frame_mbs_only_flag 0 ( 0)
@67 SPS: mb_adaptive_frame_field_flag 0 ( 0)
@68 SPS: direct_8x8_inference_flag 1 ( 1)
@69 SPS: frame_cropping_flag 0 ( 0)
@70 SPS: vui_parameters_present_flag 1 ( 1)"

im hoping "@38 SPS: num_ref_frames 011 ( 2)" is the ref values and its possible to change them to lower values in the bitstream copy without a full re-encode (or to much loss of quality playback if any ) through your ffmpeg extensions/patches if you can find a way to add that option sometime ? please.

it would be good for quick fixing streaming to the xbox360 and its limited ref 3 abilitys to play 1080AVC.Mp4 smoothly and perhaps other non (ref16) spec playback devices too.

[roozhou]

New build available, now it should work on raw H264 streams.

@popper
Now ref frames can be modified.

[popper]

roozhou thanks very much, cheers ;)

im sure that ref option will be very useful for many users devices.

[b66pak]

thanks a lot...

Now ref frames can be modified.

i think this will lead to stream decoding corruption...
_

[ExSport]

i think this will lead to stream decoding corruption...
Same opinion. Also I remember that same trick tried to use roman76r, main coder of tsMuxeR with same results=corruption when ref frames were changed to compatible l4.1

[roozhou]

i think this will lead to stream decoding corruption...
_

Yes. I changed a 16ref L5.1 stream to 8ref L4.1. DXVA can be used but shows a lot of artifacts.

[popper]

Yes. I changed a 16ref L5.1 stream to 8ref L4.1. DXVA can be used but shows a lot of artifacts.

ohh well thanks for trying it anyway, it's the same on the 360 as well, also putting the resulting ref=3 file through AVInaptic DRF analysis it goes so far through then says unknown format, and if i leave it streaming from ps3ms to the 360 it comes back 'unplayable content' after a little time, i assume as it hits the same problem part as AVInaptic gets to.

at least we now know for sure changing on the fly ref doesnt work, now how to stop average people using crazy refs and levels for the encoding general non PC hardware cases :) perhaps the tools they use need far better defaults and warnings to drum it into average end users heads, bigger numbers does not mean better quality in the average ref's and level's case.

it might be interesting to understand why changing ref to a lower Number in the sps H264 bitstream shows a lot of artifacts though,(and the unknown format so far into the file oc), after all your not adding any new ref's just using less of whats already there.

again, thanks for trying it anyway. :)

[nm]

it might be interesting to understand why changing ref to a lower Number shows a lot of artifacts though,(and the unknown format so far into the file oc), after all your not adding any new ref's just using less of whats already there.
If you change the number, you are telling one thing and doing another: the stream still uses the same number of references as before.

This is only helpful if the decoder is actually capable of buffering higher number of references but there is some kind of a gatekeeper that checks the stream properties and drops it if they exceed L4.1 limits. For example, Nvidia's hardware decoder can handle streams with 16 references, but most DXVA filters refuse to even try if the stream announces that it exceeds L4.1. In this case lying about the number of references will help, but usually it doesn't.

[roozhou]

now how to stop average people using crazy refs and levels for the encoding general non PC hardware cases :) perhaps the tools they use need far better defaults and warnings to drum it into average end users heads, bigger numbers does not mean better quality in the average ref's and level's case.

IMO this is perhaps doom9's fault. People are encouraged to buy expensive machines, use insane settings, encode at 0.xx fps and finally produce a file with "maximum" quality but cannot play on many devices. Well I would encourage people to increase bitrate by 5% and use default settings.

[SomeJoe]

This is a very nice tool, thanks.

Is there a chance that this tool could be extended to be able to modify or insert the full range, color primaries, transfer characteristics, and color matrix flags?

The reason I ask is that there are several consumer-level player devices on the market that have bugs with unflagged H.264 streams. The Western Digital TV, NMT Popcorn Hour A-100, A-110, and A-200 all will render H.264 streams with ITU601 color decoding when the H.264 stream is unflagged, regardless of the resolution. For HD streams, this is incorrect, as the rendering should be with ITU709 color decoding.

If the streams are flagged, then the incorrect color decoding does not occur.

I have several streams made from my own Blu-Rays that are unflagged. It would be most convenient/helpful if I could insert the correct color flags into these streams rather than either 1) reencode from the source, or 2) wait for Western Digital/NMT to issue firmware updates. The bugs have been raised to both companies for over a year, and they have not yet issued firmware updates.

[b66pak]

i second this request...
_

[roozhou]

New build available
Fixed bugs on flv demuxing

@SomeJoe & b66pak
Can you provide default settings for those VUI options?

[SomeJoe]

@roozhou:

I believe that the default within the H.264 stream would be that those values aren't present at all.

See this (http://www.networkedmediatank.com/showthread.php?tid=19366&pid=332936#pid332936) post over at the MNT Popcorn Hour forum. It shows a difference between what the flags look like when the color transfer information is present and when it's not:

-------- H264 Video BT.709 --------- -------- H264 Video no colour description --
video_signal_type_present_flag : 1 video_signal_type_present_flag : 1
video_format : 5 video_format : 5
video_full_range_flag : 1 video_full_range_flag : 1
colour_description_present_flag : 1 colour_description_present_flag : 0
colour_primaries : 1
transfer_characteristics : 1
matrix_coefficients : 1
chroma_loc_info_present_flag : 0 chroma_loc_info_present_flag : 0
timing_info_present_flag : 1 timing_info_present_flag : 1


I unfortunately am not familiar with the construction of an H.264 stream, so I don't know where in the stream these flags reside. I assume they're in one of the packet headers somewhere, but that's a wild guess.

You may also want to look at the whole thread (http://www.networkedmediatank.com/showthread.php?tid=19366) over there at the NMT forum, as there's a fair amount of analysis by a few of the developers.

In x264, the command line switches that would insert these flags are:

--colorprim [undef|bt709|bt470m|bt470bg|smpte170m|smpte240m|film]

--transfer [undef|bt709|bt470m|bt470bg|linear|log100|log316|smpte170m|smpte240m]

--colormatrix [undef|bt709|fcc|bt470bg|smpte170m|smpte240m|GBR|YCgCo]

[roozhou]

New build available.
Is there a chance that this tool could be extended to be able to modify or insert the full range, color primaries, transfer characteristics, and color matrix flags?

They are supported now. Well if there is no VUI in sps I cannot generate a new one.


And muxing AVC and AAC to AVI is working. The non-monotone timestamps error in mkv->mp4 muxing is fixed as well.

[b66pak]

thanks a lot...
_

[HELLFISH]

Finally!!! This is tool is so awesome. Thank you so very much for releasing it.
THANK YOU!

[roozhou]

New build available.
A bug in avi index writing is fixed. There are no longer problems in seeking.
Also added a new option "-bom utf-8", which adds the EF BB BF startcode before extracted text. It seems many windows programs(including MPC-HC) cannot recognize utf-8 encoded text without BOM so this option will fix it.

[b66pak]

thanks a lot...
_

[roozhou]

New build available.
1) Compiled with GCC 4.4.4.
2) PTS/DTS error in audio streams will be ignored.

[TheShadowRunner]

Great app, thank you very much!
(I needed to set video_full_range_flag back to 0 in a .TS)

[roozhou]

New build 24573 available.
1) Fixed two bugs in bitstream modifier, which may produce bad extradata for mp4/mkv/flv
2) Added two new option to h264_changesps: removesei and removedupheader. removesei can be used to strip x264 user data and timing info from BD. removedupheader can be used to remove duplicated sps/pps in I frames. Both are designed to reduce overhead of bitstream.

[b66pak]

thanks a lot...
_

[roozhou]

New build 24750 available.
1) Fixed a bug in bitstream parser. Now streams with seq_scaling_matrix are supported.
2) Added new option to h264_changesps: remove aud

[0028606]

I have been trying to compile this on Mac OS X 10.6 for the last coulpe of hours but it keeps give errors. If someone could please explain the process as I'm at a loss I would be very grateful

[roozhou]

What error did you get?
Plz apply my latest patch before you start.

[0028606]

Yes I have applied patch with -
Cd ffmpeg
Patch p1 < ffmpeg_svn_r24573.patch

is this the correct way to do it?

When apply the patch I get FAIL for imx_dump_header_bsf.c
ffmpeg john$ patch -p1 < ffmpeg_svn_r24573.patch
missing header for unified diff at line 5 of patch
(Stripping trailing CRs from patch.)
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: ffmpeg.c
|===================================================================
|--- ffmpeg.c (revision 24573)
|+++ ffmpeg.c (working copy)
--------------------------
File to patch: /Developer/ffmpeg/ffmpeg.c
patching file /Developer/ffmpeg/ffmpeg.c
(Stripping trailing CRs from patch.)
can't find file to patch at input line 155
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: libavcodec/aac_adtstoasc_bsf.c
|===================================================================
|--- libavcodec/aac_adtstoasc_bsf.c (revision 24573)
|+++ libavcodec/aac_adtstoasc_bsf.c (working copy)
--------------------------
File to patch: /Developer/ffmpeg/libavcodec/aac_adtstoasc_bsf.c
patching file /Developer/ffmpeg/libavcodec/aac_adtstoasc_bsf.c
(Stripping trailing CRs from patch.)
can't find file to patch at input line 177
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: libavcodec/allcodecs.c
|===================================================================
|--- libavcodec/allcodecs.c (revision 24573)
|+++ libavcodec/allcodecs.c (working copy)
--------------------------
File to patch: /Developer/ffmpeg/libavcodec/allcodecs.c
patching file /Developer/ffmpeg/libavcodec/allcodecs.c
(Stripping trailing CRs from patch.)
can't find file to patch at input line 206
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: libavcodec/avcodec.h
|===================================================================
|--- libavcodec/avcodec.h (revision 24573)
|+++ libavcodec/avcodec.h (working copy)
--------------------------
File to patch: /Developer/ffmpeg/libavcodec/avcodec.h
patching file /Developer/ffmpeg/libavcodec/avcodec.h
Hunk #8 succeeded at 3903 (offset -1 lines).
(Stripping trailing CRs from patch.)
can't find file to patch at input line 285
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: libavcodec/bitstream_filter.c
|===================================================================
|--- libavcodec/bitstream_filter.c (revision 24573)
|+++ libavcodec/bitstream_filter.c (working copy)
--------------------------
File to patch: /Developer/ffmpeg/libavcodec/bitstream_filter.c
patching file /Developer/ffmpeg/libavcodec/bitstream_filter.c
(Stripping trailing CRs from patch.)
patching file h264_changesps_bsf.c
(Stripping trailing CRs from patch.)
can't find file to patch at input line 890
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: libavcodec/h264_mp4toannexb_bsf.c
|===================================================================
|--- libavcodec/h264_mp4toannexb_bsf.c (revision 24573)
|+++ libavcodec/h264_mp4toannexb_bsf.c (working copy)
--------------------------
File to patch: /Developer/ffmpeg/libavcodec/h264_mp4toannexb_bsf.c
patching file /Developer/ffmpeg/libavcodec/h264_mp4toannexb_bsf.c
(Stripping trailing CRs from patch.)
can't find file to patch at input line 986
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: libavcodec/h264_ps.c
|===================================================================
|--- libavcodec/h264_ps.c (revision 24573)
|+++ libavcodec/h264_ps.c (working copy)
--------------------------
File to patch: /Developer/ffmpeg/libavcodec/h264_ps.c
patching file /Developer/ffmpeg/libavcodec/h264_ps.c
Hunk #1 succeeded at 37 (offset 1 line).
(Stripping trailing CRs from patch.)
can't find file to patch at input line 999
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: libavcodec/imx_dump_header_bsf.c
|===================================================================
|--- libavcodec/imx_dump_header_bsf.c (revision 24573)
|+++ libavcodec/imx_dump_header_bsf.c (working copy)
--------------------------
File to patch: /Developer/ffmpeg/libavcodec/imx_dump_header_bsf.c
patching file /Developer/ffmpeg/libavcodec/imx_dump_header_bsf.c
(Stripping trailing CRs from patch.)
patching file Makefile
Hunk #1 FAILED at 285.
Hunk #2 FAILED at 595.
2 out of 2 hunks FAILED -- saving rejects to file Makefile.rej
(Stripping trailing CRs from patch.)
can't find file to patch at input line 1032
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: libavcodec/mjpega_dump_header_bsf.c
|===================================================================
|--- libavcodec/mjpega_dump_header_bsf.c (revision 24573)
|+++ libavcodec/mjpega_dump_header_bsf.c (working copy)
--------------------------
File to patch: /Developer/ffmpeg/libavcodec/mjpega_dump_header_bsf.c
patching file /Developer/ffmpeg/libavcodec/mjpega_dump_header_bsf.c
(Stripping trailing CRs from patch.)
can't find file to patch at input line 1045
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: libavcodec/mp3_header_compress_bsf.c
|===================================================================
|--- libavcodec/mp3_header_compress_bsf.c (revision 24573)
|+++ libavcodec/mp3_header_compress_bsf.c (working copy)
--------------------------
File to patch: /Developer/ffmpeg/libavcodec/mp3_header_compress_bsf.c
patching file /Developer/ffmpeg/libavcodec/mp3_header_compress_bsf.c
(Stripping trailing CRs from patch.)
can't find file to patch at input line 1058
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: libavcodec/mp3_header_decompress_bsf.c
|===================================================================
|--- libavcodec/mp3_header_decompress_bsf.c (revision 24573)
|+++ libavcodec/mp3_header_decompress_bsf.c (working copy)
--------------------------
File to patch: /Developer/ffmpeg/libavcodec/mp3_header_decompress_bsf.c
patching file /Developer/ffmpeg/libavcodec/mp3_header_decompress_bsf.c
(Stripping trailing CRs from patch.)
can't find file to patch at input line 1071
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: libavcodec/noise_bsf.c
|===================================================================
|--- libavcodec/noise_bsf.c (revision 24573)
|+++ libavcodec/noise_bsf.c (working copy)
--------------------------
File to patch: /Developer/ffmpeg/libavcodec/noise_bsf.c
patching file /Developer/ffmpeg/libavcodec/noise_bsf.c
(Stripping trailing CRs from patch.)
can't find file to patch at input line 1084
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: libavcodec/options.c
|===================================================================
|--- libavcodec/options.c (revision 24573)
|+++ libavcodec/options.c (working copy)
--------------------------
File to patch: /Developer/ffmpeg/libavcodec/options.c
patching file /Developer/ffmpeg/libavcodec/options.c
(Stripping trailing CRs from patch.)
patching file r10kdec.c
(Stripping trailing CRs from patch.)
can't find file to patch at input line 1254
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: libavcodec/r210dec.c
|===================================================================
|--- libavcodec/r210dec.c (revision 24573)
|+++ libavcodec/r210dec.c (working copy)
--------------------------
File to patch: /Developer/ffmpeg/libavcodec/r210dec.c
patching file /Developer/ffmpeg/libavcodec/r210dec.c
(Stripping trailing CRs from patch.)
can't find file to patch at input line 1298
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: libavcodec/remove_extradata_bsf.c
|===================================================================
|--- libavcodec/remove_extradata_bsf.c (revision 24573)
|+++ libavcodec/remove_extradata_bsf.c (working copy)
--------------------------
File to patch: /Developer/ffmpeg/libavcodec/remove_extradata_bsf.c
patching file /Developer/ffmpeg/libavcodec/remove_extradata_bsf.c
(Stripping trailing CRs from patch.)
can't find file to patch at input line 1314
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: libavformat/assenc.c
|===================================================================
|--- libavformat/assenc.c (revision 24573)
|+++ libavformat/assenc.c (working copy)
--------------------------
File to patch: /Developer/ffmpeg/libavformat/assenc.c
patching file /Developer/ffmpeg/libavformat/assenc.c
(Stripping trailing CRs from patch.)
can't find file to patch at input line 1330
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: libavformat/avienc.c
|===================================================================
|--- libavformat/avienc.c (revision 24573)
|+++ libavformat/avienc.c (working copy)
--------------------------
File to patch: /Developer/ffmpeg/libavformat/avienc.c
patching file /Developer/ffmpeg/libavformat/avienc.c
(Stripping trailing CRs from patch.)
can't find file to patch at input line 1534
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: libavformat/flvenc.c
|===================================================================
|--- libavformat/flvenc.c (revision 24573)
|+++ libavformat/flvenc.c (working copy)
--------------------------
File to patch: /Developer/ffmpeg/libavformat/flvenc.c
patching file /Developer/ffmpeg/libavformat/flvenc.c
(Stripping trailing CRs from patch.)
can't find file to patch at input line 1577
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: libavformat/isom.c
|===================================================================
|--- libavformat/isom.c (revision 24573)
|+++ libavformat/isom.c (working copy)
--------------------------
File to patch: /Developer/ffmpeg/libavformat/isom.c
patching file /Developer/ffmpeg/libavformat/isom.c
(Stripping trailing CRs from patch.)
can't find file to patch at input line 1589
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: libavformat/matroskadec.c
|===================================================================
|--- libavformat/matroskadec.c (revision 24573)
|+++ libavformat/matroskadec.c (working copy)
--------------------------
File to patch: /Developer/ffmpeg/libavformat/matroskadec.c
patching file /Developer/ffmpeg/libavformat/matroskadec.c
(Stripping trailing CRs from patch.)
can't find file to patch at input line 1666
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: libavformat/matroskaenc.c
|===================================================================
|--- libavformat/matroskaenc.c (revision 24573)
|+++ libavformat/matroskaenc.c (working copy)
--------------------------
File to patch: /Developer/ffmpeg/libavformat/matroskaenc.c
patching file /Developer/ffmpeg/libavformat/matroskaenc.c
(Stripping trailing CRs from patch.)
can't find file to patch at input line 1715
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: libavformat/mov.c
|===================================================================
|--- libavformat/mov.c (revision 24573)
|+++ libavformat/mov.c (working copy)
--------------------------
File to patch: /Developer/ffmpeg/libavformat/mov.c
patching file /Developer/ffmpeg/libavformat/mov.c
(Stripping trailing CRs from patch.)
can't find file to patch at input line 1736
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: libavformat/movenc.c
|===================================================================
|--- libavformat/movenc.c (revision 24573)
|+++ libavformat/movenc.c (working copy)
--------------------------
File to patch: /Developer/ffmpeg/libavformat/movenc.c
patching file /Developer/ffmpeg/libavformat/movenc.c
(Stripping trailing CRs from patch.)
can't find file to patch at input line 1782
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: libavformat/raw.c
|===================================================================
|--- libavformat/raw.c (revision 24573)
|+++ libavformat/raw.c (working copy)
--------------------------
File to patch: /Developer/ffmpeg/libavformat/raw.c
patching file /Developer/ffmpeg/libavformat/raw.c
(Stripping trailing CRs from patch.)
can't find file to patch at input line 1849
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: libavformat/riff.c
|===================================================================
|--- libavformat/riff.c (revision 24573)
|+++ libavformat/riff.c (working copy)
--------------------------
File to patch: /Developer/ffmpeg/libavformat/riff.c
patching file /Developer/ffmpeg/libavformat/riff.c
(Stripping trailing CRs from patch.)
can't find file to patch at input line 1894
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: libavformat/rmdec.c
|===================================================================
|--- libavformat/rmdec.c (revision 24573)
|+++ libavformat/rmdec.c (working copy)
--------------------------
File to patch: /Developer/ffmpeg/libavformat/rmdec.c
patching file /Developer/ffmpeg/libavformat/rmdec.c
(Stripping trailing CRs from patch.)
can't find file to patch at input line 1906
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: libavformat/utils.c
|===================================================================
|--- libavformat/utils.c (revision 24573)
|+++ libavformat/utils.c (working copy)
--------------------------
File to patch: /Developer/ffmpeg/libavformat/utils.c
patching file /Developer/ffmpeg/libavformat/utils.c



This is the Error I can't get past
CC libavcore/utils.o
LD libavcore/libavcore.0.dylib
ld: warning: -read_only_relocs cannot be used with x86_64
LD libavcodec/libavcodec.52.dylib
ld: warning: -read_only_relocs cannot be used with x86_64
Undefined symbols:
"_r10k_decoder", referenced from:
_avcodec_register_all in allcodecs.o
"_h264_changesps_bsf", referenced from:
_avcodec_register_all in allcodecs.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [libavcodec/libavcodec.52.dylib] Error 1

[J_Darnley]

Yes I have applied patch with -
Cd ffmpeg
Patch p1 < ffmpeg_svn_r24573.patch

is this the correct way to do it?

No, you don't need to strip any levels from the paths (-p0)

[roozhou]

I have uploaded the new patch (ffmpeg_svn_r24750.patch). Update to svn 24750 and apply the patch.

P.S. why did you use "p1"?

[0028606]

I have uploaded the new patch (ffmpeg_svn_r24750.patch). Update to svn 24750 and apply the patch.

I do not see 24750 on the svn linked

P.S. why did you use "p1"?

The answer to that one is short,

No idea why....



EDIT.....

I see it on the SVN now thank you

[b66pak]

@roozhou thanks a lot...
_

[J_Darnley]

Hey all, I wanted to use this tool today so I decided to build it. It wouldn't apply on top of my other patches, and it wouldn't build on a clean source. So I decided to cut out the functional bits. You can get them here: http://users.telenet.be/darnley/ffmpeg/

These are from git format-patch and the ones from this thread start at 3. Not all the code is there yet

[roozhou]

@J_Darnley
The first version of ffmpeg_svn_r24750.patch contains debug code in h264_changesps_bsf.c. It will dump extra data to files before and after modification. Please check out the latest version from svn or just remove two fopen-fwrite-fclose sections in h264_changesps_filter function.