On 02/13/2016 01:03 PM, Mats Peterson wrote:
On 02/13/2016 01:00 PM, Mats Peterson wrote:
On 02/13/2016 12:58 PM, Mats Peterson wrote:
On 02/13/2016 12:57 PM, Mats Peterson wrote:
On 02/13/2016 12:54 PM, Mats Peterson wrote:
On 02/13/2016 12:52 PM, Mats Peterson wrote:
just double checked, this is not the case in written pal8 nut files
nor does the nut spec say anything about that.
Then check an odd-width nut file like the one below. And FFmpeg
doesn't
care about specs when using "-vcodec copy". The stride will be the
one
of the original data, whether it's 2, 4 or some other amount of
bytes.
The stride will be *aligned* to 2, 4 or some other amount of bytes.
Mats
Try "ffmpeg -i 8bpp_129.avi -vcodec rawvideo 8bpp_129.nut" with the
file
below. It will have a stride aligned to 4 bytes like the original AVI
file, and per the Microsoft specification, since it doesn't "-vcodec
copy" won't touch the video data.
https://drive.google.com/open?id=0B3_pEBoLs0faekxWUTdkVGNTTlk
_______________________________________________
I mean "ffmpeg -i 8bpp_129.avi -vcodec copy 8bpp_129.nut" of course.
Mats
The stride will be 132 bytes, divisible by 4, rather than 129 bytes.
Mats
Now the problem is that it won't show any video, since the incorrect
codec tag RGB[15] will be written to the nut file, and it's not possible
to use "-vtag" to set tha PAL[8] codec tag, but if you use "-v debug"
you will see that the stride is 132 bytes.
Mats
_______________________________________________
What's more, no palette will be included in the frames, since "-vcodec
copy" once again doesn't touch the original AVI data. So it's pretty
useless to use "-vcodec copy" for pal8.
Mats
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
