Re: [vdr] VDR File splitting validation

2012-09-05 Thread Udo Richter

Am 05.09.2012 11:13, schrieb Rares Pop:

You were saying that  VDR does splitting and editing on the data
stream level, not on the audio/video-track level. Am I to understand
that vdr doesn't make the files at the beginning of a video I-frame?


The video stream gets split at a TS packet that contains an I-Frame / 
GOP start of the VPID video stream, thats true. But all other streams 
get split just at that same point in the data stream, not necessarily at 
any special boundaries.


Cheers,

Udo

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] VDR File splitting validation

2012-09-05 Thread Rares Pop
Thanks for the response and the vdrnfofs tip.
At the moment we're doing some post processing to deal with this, by bringing 
back the audio from the next file.

You were saying that  VDR does splitting and editing on the data stream level, 
not on the audio/video-track level. 
Am I to understand that vdr doesn't make the files at the beginning of a video 
I-frame?

Kind regards,
Rares

On Sep 4, 2012, at 11:55 PM, Udo Richter  wrote:

> Am 04.09.2012 15:22, schrieb Rares Pop:
>> Now, when VDR does the file split (after the quota has been met and a
>> video I-Frame is about to start) the audio packets that would be in
>> sync with the latest video frames before the split are actually being
>> contained in the next split file.
> 
> Thats because VDR does splitting and editing on the data stream level, not on 
> the audio/video-track level. Merging all the file pieces together always 
> gives the original stream, with just very minor modifications.
> 
> Editing based on time stamps would be a lot more difficult, as near the 
> splitting point, data needs to be moved to the previous/next file, depending 
> on whether audio is ahead/behind video. To make things more complicated, 
> there's no guarantee that together with the I-frame also a new audio frame 
> starts at the exact time stamp. For precise editing, an audio frame may have 
> to be split and re-compressed.
> 
> And for playback, the same applies in reverse: For pre-buffering, the 
> A/V-data of the file end and beginning needs to be merged with proper offset 
> again. This is all a lot more complicated than just splitting the whole data 
> stream as one.
> 
> For further processing, its the best to merge continuous stream parts into 
> one big file, if the program cannot handle split files on its own. If you 
> want to avoid the copying, take a look at vdrnfofs, a virtual file system 
> that virtually merges VDR recordings into single mpg files.
> 
> 
> Cheers,
> 
> Udo
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 




-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] VDR File splitting validation

2012-09-04 Thread Udo Richter

Am 04.09.2012 15:22, schrieb Rares Pop:

Now, when VDR does the file split (after the quota has been met and a
video I-Frame is about to start) the audio packets that would be in
sync with the latest video frames before the split are actually being
contained in the next split file.


Thats because VDR does splitting and editing on the data stream level, 
not on the audio/video-track level. Merging all the file pieces together 
always gives the original stream, with just very minor modifications.


Editing based on time stamps would be a lot more difficult, as near the 
splitting point, data needs to be moved to the previous/next file, 
depending on whether audio is ahead/behind video. To make things more 
complicated, there's no guarantee that together with the I-frame also a 
new audio frame starts at the exact time stamp. For precise editing, an 
audio frame may have to be split and re-compressed.


And for playback, the same applies in reverse: For pre-buffering, the 
A/V-data of the file end and beginning needs to be merged with proper 
offset again. This is all a lot more complicated than just splitting the 
whole data stream as one.


For further processing, its the best to merge continuous stream parts 
into one big file, if the program cannot handle split files on its own. 
If you want to avoid the copying, take a look at vdrnfofs, a virtual 
file system that virtually merges VDR recordings into single mpg files.



Cheers,

Udo

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr