0.7.1SE - Lets get going.

[s55]

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.

[dynaflash]

I have no idea where to start getting rev 48 x264 level 3.0 capable....

[s55]

Don't worry about it dynaflash, we'll get there. Your not the only 1 working on the project

[dynaflash]

Don't worry about it dynaflash, we'll get there. Your not the only 1 working on the project

Okay, i get it. Rev 48 it is then...

[jbrjake]

I have no idea where to start getting rev 48 x264 level 3.0 capable....

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:

Code: Select all

6B 68 40 F2 5F 24 4F  
C5 BA 39 A5 1B CF 03 23 F3

...those are the magic words to make iTunes/iPod recognize the video.

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);
+    }

But all those functions (mov_write_avcc_tag(), put_be32(), put_tag()) are all part of ffmpeg. So the difficulty is translating that to something libmp4v2, which is much more bare-bones and do-it-yourself, can understand. I have no idea where to even start, with that.

[dynaflash]

Does anyone ?

[s55]

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

[rhester]

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

[s55]

ah ok then, Thats cool

[Thierry]

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.

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

[dynaflash]

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:

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.

As well, we can check and see if the sleep value was reset back to 50 instead of 200 from the previous threading changes.

This is just an idea, I would like to see what you guys think?