Encoding from point A to point B

[dynaflash]

Okay ... so reviving a long dead thread. Given HB's obvious success with ffmpeg input ... it only seems natural that we look back to the concept of not only chapters for encoding in and out points, but also maybe time ... or better yet frame based in and out points. As has been illustrated previously in this thread ... the obstacles are many. However, in an effort to try to toss another stone into the libhb dev pond ... I did a quick hack to the macgui based on Van's previous work to make live preview work properly based on a preview every x % of the sources duration. This hack (and I do mean hack) presumes that the announced duration upon scan is correct, which is of course quite possibly false. However being thick headed I went ahead and told the macgui that there is a preview for every second of the source title and furthermore tried to accomplish a "very rough and crude" point a to point b encoding option based on about 1 second time granularity. For what it's worth, here is the patch to the macgui: http://handbrake.fr/pastebin/pastebin.php?show=1062 .

Note this also takes from information found at the live preview thread here: http://forum.handbrake.fr/viewtopic.php ... ve+Preview

Now, from a technical standpoint you will get no argument from me as to its technical lack of merit. However ... realize I am *only* tossing this out here to stimulate further testing and consideration for all devs.

Note: In my intial testing and against my current library I have found this: For dvd's against the source timestamps in dvdplayer.app I am about 15 seconds off. However against the same time stamp in the vlc scrubber its within about 1 second. Oddly against my ( admittedly small ) library of mvks and other assorted non-dvd input it seems to be more accurate.

[dynaflash]

Here is a screenshot of the primitive implementation in the macgui:



The activity log should show what you should expect and compare to in various players against your source:

Code: Select all

[17:04:01] macgui: point a to b should start at: 600 seconds
[17:04:01] macgui: point a to b should start at (hh:mm:ss): 00:10:00
[17:04:01] macgui: point a to b duration: 73 seconds
[17:04:01] macgui: point a to b duration (hh:mm:ss): 00:01:13
[17:04:01] macgui: point a to b should end at: 673 seconds
[17:04:01] macgui: point a to b should end at (hh:mm:ss): 00:11:13

... which is admittedly over verbose but should serve for testing.

[eddyg]

I haven't looked at the patch. But I assume you are seeking to the point. Have you considered starting at the start get all the content and discard buffers until the correct timestamp come through?

[dynaflash]

I haven't looked at the patch. But I assume you are seeking to the point. Have you considered starting at the start get all the content and discard buffers until the correct timestamp come through?

eddyg: I am simply bastardizing what van gave me for live preview. I simply set

Code: Select all

job->seek_points = (title->hours * 3600) + (title->minutes * 60) + (title->seconds);
job->start_at_preview = start_seconds; <-- which is the specified number of seconds to start at
job->pts_to_stop = stop_seconds * 90000LL; <--- which is the duration to encode ala preview deduced by getting the diff from start to stop in the gui.

Given that hb presumes a preview based on every second ( as opposed to on a percentage of the title duration ) the start second roughly correlates to what hb sees as a "preview". Notice in the patch no changes to libhb.

Though as always I welcome any fixes by those that know more than me

[dynaflash]

Note, be sure to copy and paste the diff into a text editor instead of downloading the diff. Our pastebin has text encoding issues when it comes to the xib part of the diff. Otherwise the patch will apply but it will not build.

[BradleyS]

I can verify that on most sources (various containers and durations) this does appear to be start-time accurate within one second, and produces the requested duration. With transport streams the start time can be off by as much as 30 seconds or more, but this is expected given van's comments: http://forum.handbrake.fr/viewtopic.php ... 498#p37066.

I am reminded that Blu-ray disc uses the M2TS container (a few variants exist outside of this application, we'll ignore those for now), which is basically identical to TS with an additional 4 bytes of timing info added to each packet. I'm curious if this additional information is used to assist with seeking and if so, it would be interesting to see if M2TS-capable muxers create this timing information or simply pad each packet with an additional 4 bytes. I'm not suggesting that padding would be compliant; it's an unfounded theory for sure. Anyway, these are just some thoughts...

Clearly, as this feature matures an improved UI may be needed, but even in this crude state the functionality does not add clutter and it is useful. It sounds like ensuring to-the-frame accuracy given a variety of inputs will be the biggest hurdle. Not a bad start at all.

[dynaflash]

New version which is clean against svn head and also has a bit clearer activity log readouts:

http://handbrake.fr/pastebin/pastebin.php?show=1080

Please copy and paste the patch text and save as a diff ( remember should end on a new line ). As previously mentioned downloading the diff causes formatting issues when it comes to the xib part.

[ncbp]

I know that this comment probably isn't worth much when not accompanied by a patch, but... It would be so cool if the preview window could be used as a scrubber to insert in and out points to be used for encoding. In any case, this is heading in a very nice direction
Tnx,
ncbp

[dynaflash]

It would be so cool if the preview window could be used as a scrubber to insert in and out points to be used for encoding.

No doubt. The UI part of the patch is about as minimal as I can make it for testing. This is only proof of concept. If it were found to be workable there are many ui possibilities to say the least. Right now some testing on various sources is needed.

[dynaflash]

New patch which also enables chapters. Previous patch stupidly ignored the chapter settings.

http://handbrake.fr/pastebin/pastebin.php?show=1085

[JohnAStebbins]

Here's a patch that adds pts start and frame start capability to libhb.
http://handbrake.fr/pastebin/pastebin.php?show=1086

It's brute force. When a start pts is specified, reader inspects and drops all buffers till the desired pts is found. When a start frame is specified, sync inspects and drops all buffers till the desired frame is found. Note that since frame searching is done in sync, all frames are decoded. Whereas pts searching does not require decoding.

The new job variables are pts_to_start and frame_to_start. pts_to_stop and frame_to_stop must still be specified as offsets from the start point. I've wired up the gtk ui and the cli (--start-at unit:#).



EDIT: Forgot to mention, there is a new state in hb_state_t param.working.state called HB_STATE_SEARCHING
During this state, progress, hours, minutes, seconds, job_cur, job_count, and unique_id are all valid. progress and eta tell how much time is left till start point is found. So in the gtk ui and cli I display an appropriate message during the search phase.

[JohnAStebbins]

Here's an updated patch that fixes the initial bad frame issue with ffmpeg sources when doing a pts based start point.
http://handbrake.fr/pastebin/pastebin.php?show=1094

As a side effect, finding the time based start point for sources that have an index is instantaneous.

[JohnAStebbins]

Another update.
http://handbrake.fr/pastebin/pastebin.php?show=1095

In the last patch, I used av_frame_seek to seek to the nearest I-frame after the timestamp we wanted. This isn't very accurate since i-frames can be pretty sparse. So this patch seeks to the nearest i-frame before the timestamp we want. Then frames are decoded and inspected in sync until we reach exactly the desired timestamp.

[dynaflash]

So, here is a new patch which includes John's latest libhb changes and the macgui changes necessary to implement both seconds and frames as well as our current chapters for start and end points:

http://handbrake.fr/pastebin/pastebin.php?show=1096

Duration changes when seconds or frames are chosen or edited. General layout is obviously still up in the air, but should suffice for now. I am using text fields for seconds and frames still as I am not convinced IB steppers are worth the code complexity at this point. Queue window accurately reflects chapter, seconds or frames chosen. Additonally the macgui reports expected pts and frame results in the activity log.

Note: Seconds and frames based encoding is not sanity checked yet (meaning you can currently specify seconds or frames beyond eof) but that is small potatoes. Also, I have left my original preview code based time to time code in but have commented it out. I will obviously kill it but for now am leaving it there. It's only benefit is its speed ( no brute force scan ) though I acknowledge that its lack of accuracy is probably not worth its inclusion ( which in the case of TS sources is wicked to the tune of 30 + secs off ).

One question: Should we leave chapter markers enabled if doing pts or frame encoding ? Right now I have not touched them meaning if the desired pts or frames point to point encode spans a chapter, the chapter marker is still included.

My own opinion: While this is for right now probably not a huge feature in its current ui implementation ... I do think that offering it ( especially in light of John's huge improvement in libhb over my original preview based hack ) is well worth it for HandBrake. It seems to me this is something that can be built on. Given the UI's default to our existing chapter based encoding, I see no real downside to offering pts and frame based point to point at this time to HandBrake. The potential additional functionality pts and frame based point to point offers, given HandBrakes vastly improved ffmpeg input capabilites is in my mind a natural extension of what should be well within the purview of HandBrakes offerings to the user.

[BradleyS]

+1 for letting the user determine chapter markers. Worst case is the output will not begin with a chapter marker, but this should be expected behavior.

[JohnAStebbins]

My latest.
http://handbrake.fr/pastebin/pastebin.php?show=1099

Minor changes. Fix for ffmpeg streams whose first timestamp is not 0. Allow chapter markers during p-to-p.
I feel this is ready to be checked in.

[dynaflash]

I agree.

[dynaflash]

fwiw john checked in the libhb, cli and lingui changes and I checked in the macgui changes:
http://trac.handbrake.fr/changeset/3039
http://trac.handbrake.fr/changeset/3040
http://trac.handbrake.fr/changeset/3041
http://trac.handbrake.fr/changeset/3042