0.7.1SE - Lets get going.
Forum rules
*******************************
Please be aware we are now using GitHub for issue tracking and feature requests.
- This section of the forum is now closed to new topics.
*******************************
*******************************
Please be aware we are now using GitHub for issue tracking and feature requests.
- This section of the forum is now closed to new topics.
*******************************
0.7.1SE - Lets get going.
Lets make the current Trunk a branch.
Then Stick rev48 up as the new Trunk so we can begin work on it.
Things which we are going to do with 0.7.1SE
- Update the GUI with Fixes so it works correctly
- Make changes to the jam files so that it'll compile on windows.
- Add 640 5G IPOD support
- We need to update the downloads so that they use the correct older versions and we don't try and compile it with all the newer encoders etc
One thing i seriously suggest doing also is this:
- Update LivDvdCss and LibDvdRead
I am hoping that this will resolve a few issues on the windows port that are causing stack dumps on a regular basis. It shouldn't be too hard to change.
How does that sound? If all is good can someone make the changes to the trunk.
Then Stick rev48 up as the new Trunk so we can begin work on it.
Things which we are going to do with 0.7.1SE
- Update the GUI with Fixes so it works correctly
- Make changes to the jam files so that it'll compile on windows.
- Add 640 5G IPOD support
- We need to update the downloads so that they use the correct older versions and we don't try and compile it with all the newer encoders etc
One thing i seriously suggest doing also is this:
- Update LivDvdCss and LibDvdRead
I am hoping that this will resolve a few issues on the windows port that are causing stack dumps on a regular basis. It shouldn't be too hard to change.
How does that sound? If all is good can someone make the changes to the trunk.
Getting it level 3 capable is the easy part. The tough part will be getting it to spit out those level 3 x264 videos with these numbers in the .mp4 header:dynaflash wrote:I have no idea where to start getting rev 48 x264 level 3.0 capable....
Code: Select all
6B 68 40 F2 5F 24 4F
C5 BA 39 A5 1B CF 03 23 F3
The guy who writes VisualHub explained it in detail when he patched ffmpeg to do iPod 5.5G: http://lists.mplayerhq.hu/pipermail/ffm ... ]"Baseline Low-Complexity" is something they made up. It basically
means "Baseline with 1 reference frame".
After a weekend of trial, error, hex reading, and headaches, I
learned the following:
Apple is using special tags to prevent iTunes from accepting 3rd-
party-created .mp4 files.
This seems to be similar to the PSP limitations. I remember talk of
adding a "-f ipod" option to movenc.c a few months back. It seems
like a good idea to add it now...
Baseline Low-Complexity Profile Details:
1 reference frame.
No higher than Level 30.
640px is max width. No exceptions.
Must have a SAR. 1:1 is the correct setting.
Must have uuid atom with the following hex data: 6B 68 40 F2 5F 24 4F
C5 BA 39 A5 1B CF 03 23 F3
^^ that uuid atom is crucial. If it's removed (or altered) in a known-
working QuickTime-created file, iTunes will refuse to place it on the
iPod.[/quote]
Now, getting that to work in ffmpeg is easy: http://www.techspansion.com/movenc.diff
Code: Select all
+ else if(track->enc->codec_id == CODEC_ID_H264) {
+ mov_write_avcc_tag(pb, track);
+ if (track->mode != MODE_PSP) {
+ put_be32(pb, 0x34); /* size ... reports as 28 in mp4box! */
+ put_tag(pb, "uuid");
+ put_be32(pb, 0x6B6840F2);
+ put_be32(pb, 0x5F244FC5);
+ put_be32(pb, 0xBA39A51B);
+ put_be32(pb, 0xCF0323F3);
+ }
Can someone setup a new trunk named 0.7.1SE and move the current 0.7.2 trunk to a branch. I'd do it myself but i'm unfamiliar with svn and i really dont wanna screw things up
Onces its up people can start making changes.
Rev48: It doesnt compile on windows and it seems like its going to take alittle more work than the previos build as i tried making some of mirkwoods changes but still ran into problems. We'll work this out
Onces its up people can start making changes.
Rev48: It doesnt compile on windows and it seems like its going to take alittle more work than the previos build as i tried making some of mirkwoods changes but still ran into problems. We'll work this out
Dear all,
I have been following this forum for a while and I really do appreciate all the work from all the new the developpers after Titer seems to have "abandon" work on his project.
I'm eager to try the new Hanbrake to try to copy my personnal collection of DVD.
I just try to do one the other night with titer software (I have been using it since april last year after buying my new (and first) MacBook Pro).
It took me 29 minutes to copy a 23 minutes cartoon (it was a 2 pass encoding).
I think I will not mind accepting this "Memory Leak" until you guys figure it out.
I hope to be able to use it soon
Sincerely,
Thierry
PS: keep up the good work
PPS: I would like to submit one request: I do not know how difficult it will be to be able to add subtitle track from file like this web site provide: http://www.cswap.com/1966/La_Grande_vadrouille# they are .srt files and I do not know how they will be able to get incorporated in Handbrake.
I have been following this forum for a while and I really do appreciate all the work from all the new the developpers after Titer seems to have "abandon" work on his project.
I'm eager to try the new Hanbrake to try to copy my personnal collection of DVD.
I just try to do one the other night with titer software (I have been using it since april last year after buying my new (and first) MacBook Pro).
It took me 29 minutes to copy a 23 minutes cartoon (it was a 2 pass encoding).
I think I will not mind accepting this "Memory Leak" until you guys figure it out.
I hope to be able to use it soon
Sincerely,
Thierry
PS: keep up the good work
PPS: I would like to submit one request: I do not know how difficult it will be to be able to add subtitle track from file like this web site provide: http://www.cswap.com/1966/La_Grande_vadrouille# they are .srt files and I do not know how they will be able to get incorporated in Handbrake.
rhester wrote:This may not be necessary.
The poll on m0k's HandBrake General forum suggests that users would be willing to live for the memory leak for a while.
Rodney
Well, if we decide to move ahead with libavformat and not regress to svn rev 48. It seems to me the question then becomes, which current rev do we branch to 0.7.1 SE ?
I might suggest our latest trunk rev 105. My thinking is that johnallens addition of the barber pole progress bar during the muxing phase will help dissuade users fears that the app has crashed.
svn rev105 log message from john allen:
This is just an idea, I would like to see what you guys think?
I might suggest our latest trunk rev 105. My thinking is that johnallens addition of the barber pole progress bar during the muxing phase will help dissuade users fears that the app has crashed.
svn rev105 log message from john allen:
As well, we can check and see if the sleep value was reset back to 50 instead of 200 from the previous threading changes.barber pole progress bar is shown during the "muxing" phase and no longer show 0.0%. applies to both HB and IHB
When we can figure out how to get a percent complete, we can use that.
IHB now uses same app icon as HB. Probably want to change the actual icon, but I wanted IHB to make use of the dock progress bar like in HB.
This is just an idea, I would like to see what you guys think?