|
|
| Matrosko |
| Posted: Jul 8 2011, 04:53 PM |
 |
|
Newbie
Group: Members
Posts: 5
Member No.: 32072
Joined: 8-July 11
|
Hi.
I'm adding forced subtitle with vsfilter in blend mode with opacity curve to select only the zone where the subtitle are.
Encoder used is x264wfv and fcchandler to load matroska.
Anyway the render works very well with normal x264 (tested on PS3).
Bypassed content appended to recoded ones play without breaks or any visibile damage because the cut is done on I frames.
The problem comes with Open gop structure where there is not IDR-frames (Instantaneous Decoder Refresh) and the cut must be done on RPS-frame (frame Recovery Point SEI).
In these type of x264 the I frame is placed in the middle of the GOP.
A kind of xplanation of open gop can be found here.
http://doom10.org/index.php?topic=529.0
The resulting rendering seems to play fine on pc with libavcodec but on PS3 the very next GOP appended after a rended one appears dameged and incomplete (mixed frames and macroblocks). The video plays normally only when the "Damaged GOP" ends and next GOP begin.
There is a chance to correct open gop handling?
Sorry for my english. |
|
| stephanV |
| Posted: Jul 9 2011, 08:04 AM |
|
|
Spam killer ;)
Group: Moderators
Posts: 4348
Member No.: 8917
Joined: 18-February 04
|
VirtualDub doesn't even know there is such a thing as a GOP. VFW is not really made for this.
--------------------
useful links:
VirtualDub, Input plugins and filters, AviSynth, AVI-Mux GUI, AC3ACM by fcchandler, VirtualDub FAQ |
|
| Matrosko |
| Posted: Jul 9 2011, 01:02 PM |
|
|
Newbie
Group: Members
Posts: 5
Member No.: 32072
Joined: 8-July 11
|
| QUOTE (stephanV @ Jul 9 2011, 08:04 AM) | | VirtualDub doesn't even know there is such a thing as a GOP. VFW is not really made for this. |
A software made to cut and edit video streams doesnt know GOPs ?
x264vfw works well
http://en.wikipedia.org/wiki/Group_of_pictures
I think u just pissing me off. 
The one who doesnt even know GOPs maybe it's me?
Anyway it's just another shit on my way.
I will stay away from open gop encoded files as much i can.
thanks for helping.... |
|
| stephanV |
| Posted: Jul 9 2011, 06:30 PM |
|
|
Spam killer ;)
Group: Moderators
Posts: 4348
Member No.: 8917
Joined: 18-February 04
|
Inf VFW there are only key frames (which can always be decoded) and delta frames (which can only be decoded if the frame before that is correctly decoded). There is no such thing as B-frames, there is no such thing as an open GOP. Within these constraints VirtualDub can edit fine.
You can't really blame VirtualDub for other people overloading VFW with constructs that it can't properly handle.
--------------------
useful links:
VirtualDub, Input plugins and filters, AviSynth, AVI-Mux GUI, AC3ACM by fcchandler, VirtualDub FAQ |
|
| Matrosko |
| Posted: Jul 10 2011, 02:19 PM |
|
|
Newbie
Group: Members
Posts: 5
Member No.: 32072
Joined: 8-July 11
|
Both B and P frames are delta frames.
...forgetting about smart render and x264...
When loading xvid vdub recognise something like...
| QUOTE |
I B P B P B P B P B P B P B P B P B P B P B P B P B P B P B P ... |
They call it GOP.
Open gop is something like this:
| QUOTE |
B P B P B P B P B P B P B P I B P B P B P B P B P B P B P B P ... |
I know that if you cut using direct stream copy and select a frame on the middle of the gop, it keeps the whole gop till the next I frame.
So it recognise the gop structure on xvid case?
Anyway x264vfw is not used to decode the stream but to encode and in the newest relese support open gop encode as x264 does.
The problem is not what x264vfw is encoding but where vdub is cutting the stream.
anyway u mistaken and my last question on the first post was:
There is a chance to correct open gop handling?
|
|
| BugMaster |
| Posted: Jul 10 2011, 08:44 PM |
|
|
Advanced Member
Group: Members
Posts: 50
Member No.: 23001
Joined: 6-February 08
|
The problem with open-gop is that you need to discard B-frames after I-frame and VirtualDub can't do this because don't know about B-frames. I will try to show you what happen here. First of there are two orders of frames:
1) display order - that is the order in which frames showed to during playback.
2) stream order - that is the order in which frames really stored in file.
With only I and P-frames all simple and stream order is usually equal to display order but with B-frames they not equal.
Here is example of simple closed GOP with B-frames:
stream order: I0 P3 B1 B2 I4 P7 B5 B6 I8 P9
display order: I0 B1 B2 P3 I4 B5 B6 P7 I8 P9
where I/P/B - frame types (for closed GOP I-frames are really IDR-frames) and number is frame number (in display order).
Let assume you change frames 2-4 with smart rendering. VirtualDub didn't know about difference between stream order and display order so it can assume that it can copy frames 0-1, re-encode 2-7 (lets assume without B-frames for simplicity) and append 8-9. That will result in:
stream order: I0 P3 I2' P3' P4' P5' P6' P7' I8 P9
display order: I0 P3 I2' P3' P4' P5' P6' P7' I8 P9
You see we already have problem because we start re-encode not from the start of GOP and so missed frame 1.
Now what happen with open GOP:
stream order: I0 I4 B1 B2 B3 I8 B5 B6 B7 P9
display order: I0 B1 B2 B3 I4 B5 B6 B7 I8 P9
And you again change frames 2-4. VitrualDub see frames 0,1,5 as key-frames (because there are in stream order) so it can assume that it can copy 0-1, re-encode 2-4, and append 5-9. That will result in:
stream order: I0 I4 I2' P3' P4' I8 B5 B6 B7 P9
display order: I0 I4 I2' P3' P4' B5 B6 B7 I8 P9
But decoder couldn't correctly decode B5 B6 B7 because they must refer to I4 but instead of it they refer to P4' which results in artifacts.
And if you add decoding lag due B-frames it became obvious that smart rendering can't be used in this situation without problems. |
|
| stephanV |
| Posted: Jul 11 2011, 05:10 AM |
|
|
Spam killer ;)
Group: Moderators
Posts: 4348
Member No.: 8917
Joined: 18-February 04
|
| QUOTE (Matrosko) |
When loading xvid vdub recognise something like...
|
No it doesn't. It sees a series of keyframes and deltaframes, not I, P and B frames.
| QUOTE |
There is a chance to correct open gop handling? |
You do not understand the response. There is no GOP "handling" in the first place. VirtualDub does not know what a GOP is (in the MPEG sense), and therefor it also can't handle open GOPs. VFW doesn't allow to differentiate between different MPEG frame types. It only knows keyframes and delta frames.
So no, it can't be corrected, because there is nothing to correct. VFW can really only do in-order decoding, and with some trick it can also do B-frames. That's it.
--------------------
useful links:
VirtualDub, Input plugins and filters, AviSynth, AVI-Mux GUI, AC3ACM by fcchandler, VirtualDub FAQ |
|
| phaeron |
| Posted: Jul 16 2011, 03:30 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
This is not actually a VFW problem, but an issue with the AVI format itself.
When VirtualDub is cutting in direct stream copy or smart rendering mode, it is bypassing video decoders and cutting the raw video stream itself. In order to do so the key frame flags must be correct on the stream to indicate when decoding can be restarted. The problem with the open GOP structure that is mentioned here is that with it the key frame flags are a lie, which is why you get a corrupted stream after editing. The key frame flags must be set only at points where decoding can be restarted and cutting will work as long as this is respected.
It is possible to cut such a stream properly, but what it actually involves is breaking the abstraction of the AVI format by interpreting the raw video stream itself according to the encoded format and using that extra information to cut the stream. This would require a lot of additional complexity and fragility that I don't want to take on.
|
|
