How to encode files (1 pass) that still grow?

[gepebril]

Hi there,

I'm just new to HandBarke after using Mencoder a lot. The results so far on CLI have been excellent.
I'm looking for a feature, that will speed up the result of encoding time. Let say I record a TV show (.ts MPEG stream) and like to start encoding 1-pass after 10 minutes after the show starts. I can do that as the fps encoding is less than the fps of the recorded file. This will save me a lot of time. Example
Show start 20:00
Show finish 21:00
Normally I can start encoding at 21:01, I like to start like 20:01 or later. If I do that now it only encodes the file part that was present when I start encoding. What should I do that it keeps encoding until the source file stops growing. Is this possible, or should I request that feature?

Thanks in advance,

Albert

[s55]

HandBrake doesn't support frame severing. The internal workflow isn't designed to handle this kind of thing I'm afraid.

You'll need the complete file.

[gepebril]

Aha,

Thanks for this information. Are you one of the developers of HandBreak?
That's a shame that the internal structure doesn't work like that. What I do see is that you can play the encoded file as soon as the encoding starts, so HandBreak doesn't first encode video, than audio and than start muxing. It seems it encodes audio + video at the same time and mux simultaneously.

If it will not be an upcoming feature of HandBrake is this "problem" solvable with Avisynth?

[gepebril]

No one?
Ok,I find a quick and maybe simple solution. Why not check at the end of an encoding if the file size grew. If so, you encode the next bit and add it to the previous encoded file. You repeat this process until the original file stops growing.I know it is not the nicest solution, but could be a quick and dirty in between solution and don't interfere with the internal workflow.

[Deleted User 11865]

This is not supported, period.

[gepebril]

Hi Rodeo,

Thanks for the reply. I will put this post at the new features section.



a person who easily gives up will never concur it's dreams.

[s55]

Ok,I find a quick and maybe simple solution. Why not check at the end of an encoding if the file size grew. If so, you encode the next bit and add it to the previous encoded file. You repeat this process until the original file stops growing.I know it is not the nicest solution, but could be a quick and dirty in between solution and don't interfere with the internal workflow.

It's way more complicated than that. Not something that's likely to ever be supported.

[gepebril]

It's way more complicated than that. Not something that's likely to ever be supported.

Thanks for the replies. I taste a little hostility in the answers, like I'm moving into an area that has many different interests. Being a programmer now and than for over more than 20 years in C, C++, Pascal, PHP, VBscript and Perl, no programmer can convince me that something like this simple is that difficult and not due able. I'm thinking that your answers are more of a political nature than an honest and open technical answer.
One of the first lessons in handling files tells you that you can append files, so the solution to trans-code what you have and append the next bit of info as you receive it is not rocket science, it's part of the first lesson in handling files. If you can't append files as it can't fit in the internal work flow, than I don't know what to think of that answer ...
Second fact is that your software can handle .ts files, which in fact is a streaming format containing MPEG2 content ....
Third, I see the following quote on your website, which I support more than 200%

"The function of good software is to make the complex appear to be simple."

So what is the real reason to use strong words like: 'period', 'ever be supported'. And do these words meet your goals as open source project and the quote just above ?

Excuses me for writing this as I find your product achieving the best quality in an easy way

Yours sincerely,

[s55]

It's not hostility. Big fan of short and to the point here.

no programmer can convince me that something like this simple is that difficult and not due able.

You're assuming it's as simple as just watching the file growing. Watching a file grow is trivial but it's significantly more complicated than that. Just trying to keep the AV in sync would be a nightmare.
You're essentially asking for a very niche feature that is unlikely to ever work reliably, therefore unlikely to ever get implemented.

[gepebril]

Hi s55,

Thanks for the long and extended reply. I used to give short and to the point answers as well. I found out that I generated more revenue as I gave up on that. It seemed that people preferred more social and long blah, blah as the opposite
I'll have to say that I'm more a person that when I hear it can't be done as this that I like to here in what way it can be done. In the Netherlands they say 'can not' is laying on the graveyard and 'will not' is laying side by side
This out of sync problem do you refer to all file types or just the MPEG2-TS files. I the past I studied the structure of this format and it is build of 188 bytes blocks and I can't imagine that audio and video have suddenly another delay at block 82351 than block 165277, correct me if I'm wrong.
Imagine that it can't be solved in Handbreak is there not a way to do it outside Handbreak and that you more or less trick this software by providing input in another matter? I haven't got real experience with Avisynth, but could that be an option?

Thanks in advance

[JohnAStebbins]

I'll have to say that I'm more a person that when I hear it can't be done as this that I like to here in what way it can be done.

You are missing the point. The issue isn't that it can't be done. The issue is that this is not what HandBrake is designed to do. HandBrake makes a pass over the file before starting an encode (the scan when you "open" the source). During this pass, HandBrake probes for a collection of information about the source. It then uses this information to automatically make a lot of choices for the user that simplify the encoding process. This pre-scan is one of HandBrake's greatest strengths. Without this pass, the user would have to specify all the relevant details about the source manually.

In your particular usage case, most of the details about the source can probably be obtained reliably in the first minute of video. But this is more often not the case. For example, calculating cropping often requires a larger more varied set of samples.

All that being said, I'm a little surprised that it stops after encoding only the portion that was present when you started the encode. If there is enough of the video present to fill in the information handbrake needs during the initial scan, the only thing that would be incorrect is the duration it guessed for the source. So I am a little curious why it stops short. The only reason I can think of is that it is actually encoding faster than the source is accumulating and reaching the end of the file.

[gepebril]

Hi John,

Thank you for the extensive reply. I'm glad that you use my expression, in which I saw an error. It should have been

I'll have to say that I'm more a person that when I hear it can't be done like this, than I like to hear in what way it can be done.

Like I've said before the power and functionality of HandBreak is very good. But when you doing a recording I don't like to wait encoding until the recording is done. Time is unfortunately money in this current world. Some people just don't like to wait...
I've tested a few times with 'growing' files and Handbreak always stops, or better said hangs when it reaches that last byte it initially scanned, even though the file still grows. In all cases I've made sure that the encoding (<= 10fps) went more slow than the growing of the file (25fps).

Like you said most things don't change after one minute of recording, and like always saving time means losing on quality..... I just like there to be an option 'growing files, which only allows one pass encoding, that only checks e.g. the first minute and don't allow automatic cropping etc. It just encodes until it reaches the last byte, in case it encodes faster than the file grows or continues if the recording is going faster then the encoding. Or just keeps encoding with the last settings it got when scanning the file. Even when it could not be an option in the GUI with the option no sync guarantied, an option in CLI would be excellent.

[hunterk]

Note: this response is meant to be helpful, not trying to fuss at you

Your situation is what's known as an "edge case." Developers can't cater to every edge case without introducing feature creep, which makes for complicated, unfriendly software.

There are plenty of video encoding software packages out there, and I'm sure some of them support file growth like you have described (a quick search suggests that FFmpeg might fit the bill). You'd be better off checking out one of those packages than trying to convince (unpaid) Handbrake devs to implement a feature they don't want to add, especially one that is such a radical departure from the current featureset.

Handbrake's main draw is it's ease of use, and this would be lost if they included every feature that gets requested.

[gepebril]

Hi Hunterk,

Thanks for the reply.
A shame that I'm on the edge of useful options. I'm trying to find a suitable solution for this problem already 3.5 years. Almost 95% of all programs is based on program stream content as input, or is Gui based (no automation possible). Due to the fact that they are PS based the provide encoding results that are out of sync. FFmpeg can never handle ts files correctly as it doesn't support the hardup option that Mencoder has. Mencoder does give a result, only AVI, not mp4 or mkv and produces streams that are the first 10 sec out of sync on most mediaplayers and don't enable ff or rewind without getting out of sync. Examples on the net to produce mkv or mp4 with X264 or mencoder all produce results which are out of sync with .ts. VLC produces poor quality and if you try your luck with professional companies they all say SD in Mpeg4, not under 2Mbit.
We supply a third world country with news from the related western country, and we like to deliver this in time. As you hear 3rd world, so not realy money available for good solutions, and bandwidth very expensive Mencoder does the job, but not too pleased with the result at the moment.
3.5 years, and I'm still fighting to achieve it, so that's why I don't like to get no for an answer. I hoped HandBreak could provide an solution, but it seems that it is not yet written in the stars that my software angel is based there ......